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Executive  Summary 


The  Defense  Logistics  Standard  Systems  (DLSS)  are  a  series  of  procedures  and 
electronic  transmission  formats  for  exchanging  logistics  data  among  DoD  ac¬ 
tivities  and,  to  a  lesser  degree,  with  civil  agencies  and  commercial  organizations. 
DLSS  electronic  transactions  convey  all  forms  of  logistics  data,  including  req¬ 
uisition  and  issue,  inventory  accounting,  finance,  and  transportation.  The  DLSS 
are  critical  to  all  of  DoD’ s  supply  operations  as  reflected  in  nearly  one  billion 
annual  exchanges. 

The  Military  Standard  Requisitioning  and  Issue  Procedures  (MILSTRIP)  were 
established  in  1962.  At  that  time  their  80-character  fixed-length  records  ex¬ 
changed  electronically  around  the  world  moved  DoD  to  the  leading  edge  of  auto¬ 
mated  logistics  operations.  Based  on  the  success  of  MILSTRIP,  several  other 
DLSS  were  established  over  the  next  15  years.  The  military  services  and  defense 
agencies  also  developed  extensive  logistics  automated  data  processing  systems 
during  that  time;  and  DLSS  procedures,  codes,  and  formats  were 
embedded  directly  into  the  computer  codes  of  these  systems. 

Now  35  years  later  the  DLSS  remain  critical  to  our  logistics  operations;  they  have 
an  annual  volume  of  two  billion  transactions,  but  they  have  become  old  and  ob¬ 
solete.  The  fixed-length  formats  are  saturated  and  do  not  permit  transmitting  ad¬ 
ditional  data.  To  compensate  for  these  limitations,  DoD  and  each  service  and 
agency  have  developed  diverse  formats  to  meet  specific  requirements.  Approxi¬ 
mately  100  million  transactions  of  unique  service  and  agency  formats  flow 
through  the  Defense  Automatic  Addressing  System  (DAAS)  annually,  and  the 
number  of  service  and  agency  transactions  that  bypass  DAAS  likely  exceeds  that 
quantity.  This  development  has  created  a  chaos  of  formats  and  systems  and  in¬ 
creased  software  costs  that  the  DLSS  were  designed  to  avoid.  Further,  the  perva¬ 
siveness  of  the  DLSS  in  legacy  systems  inhibits  the  ability  of  the  services  and 
agencies  to  modernize  the  systems  to  incorporate  new  hardware  and  software 
technologies.  Lastly,  as  DoD  attempts  to  integrate  commercial  organizations  into 
its  logistics  operations  through  third-party  logistics  arrangements,  DoD  is  forc¬ 
ing  these  outdated,  inefficient,  and  proprietary  formats  onto  its  trading  partners. 
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DoD  needs  to  replace  the  DLSS  with  another  means  of  exchanging  logistics  data. 
The  American  National  Standards  Institute’s  (ANSI’s)  Accredited  Standards 
Committee  (ASC)  XI 2  standards  for  electronic  data  interchange  (EDI)  are 
excellent  tools  for  replacing  the  DLSS.  The  ASC  XI 2  EDI  standards 

♦  are  national  commercial  standards  widely  used  in  industry  and  supported 
by  ANSI,  the  preeminent  U.S.  standards  body, 

♦  use  a  variable-length  format  and  a  flexible  syntax  that  can  be  tailored  to 
meet  DoD  requirements,  and 

♦  are  ideally  suited  to  the  extensive  use  of  computer-to-computer  data 
exchanges  that  occur  in  DoD  logistics  operations. 

Implementing  XI 2  EDI  in  place  of  the  DLSS  will  permit  DoD  to  support  ex¬ 
panding  data  requirements,  simplify  exchanges  with  commercial  trading  partners 
as  DoD  expands  its  logistics  outsourcing,  and  separate  data  exchange  formats 
from  the  internal  programming  of  logistics  computer  systems  to  permit  the 
systems  to  evolve  more  readily  with  new  technologies. 

Much  of  the  preparatory  documentation  for  implementing  EDI  in  DoD  logistics 
has  already  been  completed  by  the  Defense  Logistics  Management  Standards  Of¬ 
fice  in  developing  the  Defense  Logistics  Management  System  (DLMS).  However, 
because  of  the  extent  of  DLSS  use  in  the  DoD  logistics  infrastructure,  the  Office 
of  the  Under  Secretary  of  Defense  (Logistics)  will  need  to  coordinate  DLMS 
planning  and  implementation  effectively  with  the  military  services  and  defense 
agencies. 
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Chapter  1 

Introduction 


Background 

The  Defense  Logistics  Standard  Systems  (DLSS)  are  a  series  of  procedures  and 
electronic  transaction  formats  that  govern  DoD  logistics  operations.  DLSS  trans¬ 
actions  convey  requisition,  inventory,  transportation,  billing,  and  other  data 
among  the  logistics  automated  data  processing  (ADP)  systems  of  the  military 
services  and  defense  agencies.  Approximately  two  billion  DLSS  transactions  are 
exchanged  annually,  and  they  are  crucial  to  conduct  DoD  operations  effectively. 

However,  the  DLSS  are  more  than  35  years  old  and  are  constraining  the  growth  of 
logistics  data  exchanges  with  the  following  consequences: 

♦  Limiting  the  amount  of  data  that  can  be  transmitted.  Because  the  DLSS 
have  a  fixed-length  80-position  record  format,  they  do  not  support  the 
requirements  of  new  DoD,  service,  and  agency  initiatives. 

♦  Increasing  the  cost  of  ADP  operations.  The  services  and  agencies  design, 
program,  and  operate  solutions  that  bypass  the  DLSS  limitations. 

♦  Inhibiting  modernization  of  service  systems.  Because  the  DLSS  transaction 
formats  and  codes  are  embedded  in  the  program  code  and  data  structures 
of  many  legacy  systems,  their  enhancement  or  replacement  with  commer¬ 
cial  off-the-shelf  (COTS)  software  is  inhibited. 

♦  Increasing  the  cost  and  difficulty  of  developing  industry  partnerships  in 
third-party  logistics.  The  DLSS  are  a  DoD  proprietary  standard  and  use  an 
outdated  format. 

These  constraints  are  inhibiting  DoD’s  operational  effectiveness  as  dramatic 
changes  are  occurring  in  military  logistics.  The  environment  has  changed  from  the 
cold  war  focus  of  a  major  war  in  Europe  with  pre-positioned  forces  and  assets  to 
operations  involving  diverse  missions  anywhere  in  the  world  with  little  notice. 
DoD  needs  to  support  these  missions  with  fewer  assets  and  a  smaller  logistics 
infrastructure.  To  respond  to  these  changes,  DoD  is  developing  new  logistics 
strategies.  Recent  Office  of  the  Secretary  of  Defense  (OSD)  and  Joint  Chiefs  of 
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Staff  (JCS)  documents  describe  the  vision  of  future  military  operations  and  the 
technical  and  data  architectures  that  will  support  them.* 

Crucial  to  any  DoD  information  architecture  is  the  exchange  of  logistics  data 
among  the  activities  and  units  of  the  military  services  and  defense  agencies. 
Rather  than  continuing  to  operate  a  combination  of  DLSS  and  diverse  component- 
unique  transaction  formats,  DoD  needs  a  new  standard  system.^  To  meet  these 
requirements,  the  DLSS  should  be  replaced  with  commercial  electronic  data  inter¬ 
change  (EDI)  standards.  These  variable-length  standards  were  developed  by  the 
Accredited  Standards  Committee  (ASC)  XI 2  of  the  American  National  Standards 
Institute  (ANSI)  and  are  widely  used  by  industry  and  by  the  government  in  ex- 
changes  with  industry.  They  provide  DoD  the  flexibility  and  breadth  to  achieve 
the  logistics  data  exchanges  required  by  Joint  Vision  2010. 


Purpose 


This  report  is  intended  to  assist  DoD  logistics  managers  and  technical  staff  mem¬ 
bers  to  review  the  rationale  for  implementing  commercial  EDI  into  defense  logis¬ 
tics  data  exchanges,  participate  in  implementation  planning,  and  develop  a 
technical  approach  for  defense  logistics  operations  using  commercial  EDI. 

This  report  examines  the  current  means  of  exchanging  logistics  data  among  the 
military  services  and  the  defense  agencies,  the  need  to  change  those  means,  and 
the  replacement  technology.  The  report  also  identifies  the  key  organizations  that 
need  to  participate  in  the  migration  to  the  new  system  and  provides  an  overview 
of  a  migration  strategy.  The  report  concludes  with  a  description  of  the  technical 
approach  for  operating  in  an  EDI  environment. 

Organization 

The  remainder  of  this  report  is  organized  as  follows: 

♦  Chapter  2  describes  the  current  logistics  environment,  the  uses  and  limita¬ 
tion  of  the  DLSS,  and  the  rationale  for  replacing  them  with  commercial 
EDI.  Appendix  A  provides  additional  information  about  the  development 
of  DLSS  and  its  replacement. 


^  The  documents  include  Joint  Vision  2010  by  the  Chairman  of  the  JCS  and  a  series  of  docu¬ 
ments  published  by  the  Deputy  Under  Secretary  of  Defense  (Logistics).  Appendix  C  identifies 
these  documents. 

^  The  DoD  components  include  the  military  departments  and  defense  agencies. 

^  The  XI 2  standards  for  EDI  are  also  a  federal  government  standard,  Federal  Information 
Processing  Standard  (FIPS)  161-2,  May  1996.  In  this  report  the  term  “EDI”  is  used  synonymously 
for  the  ASC  X12  EDI  standards.  In  its  broadest  sense  EDI  can  encompass  other  formats,  and  the 
DLSS  themselves  were  an  early  form  of  EDI  that  helped  generate  the  XI 2  standards. 
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Introduction 


♦  Chapter  3  identifies  organizational  roles  and  responsibilities  and 
implementation  goals. 

♦  Chapter  4  identifies  the  steps  to  conduct  implementation  planning  and 
presents  a  representative  approach  to  phased  implementation. 

♦  Chapter  5  provides  cost  and  benefit  estimates. 

♦  Chapter  6  describes  how  DoD  can  implement  commercial  EDI  technology 
in  its  functional  and  technical  environment.  (Appendix  B  provides 
additional  information  on  technical  issues.) 

♦  Chapter  7  summarizes  the  report. 
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Chapter  2 

Need  to  Revise  Logistics  Data  Exchanges 


Current  Environment 

Defense  Logistics  Standard  Systems 

DoD  established  the  Military  Standard  Requisitioning  and  Issue  Procedures 
(MILSTRIP)  in  July  1962.  MELSTRIP  defined  DoD  procedures  and  transaction 
formats  for  the  inter-service/agency  requisitioning  of  materiel  and  related  transac¬ 
tions  that  previously  were  accomplished  only  by  memorandums  of  understanding 
between  the  military  services  and  defense  agencies  by  commodity.  The  introduc¬ 
tion  of  standard  procedures  and  electronic  formats  was  immensely  successful. 
Based  on  the  success  of  MILSTRIP,  DoD  expanded  the  standard  logistics 
processes  during  the  next  16  years  as  shown  in  Table  2-1. 

Table  2-1.  The  13  Defense  Logistics  Standard  Systems 


System 

Year 

acronym 

Function 

established 

MILSTRIP 

Requisition  and  Issue 

MILSTAMP 

Transportation  and  Movement 

MILSTRAP 

Transaction  Reporting  and  Accounting  (wholesale  inven¬ 
tory  management) 

1965 

MILSTEP 

Supply  and  Transportation  Evaluation  (measures  fill  rate 
and  response  time  to  requisitions) 

1968 

SDR 

Supply  Discrepancy  Report  (formerly  called  Report  of 
Discrepancy  [ROD]) 

1968 

MILSCAP 

Contract  Administration 

1970 

MILSBILLS 

Billing  and  Funds  Transfer 

1973 

MILSPETS 

Petroleum 

1978 

Directories  and  supporting  systems 

DoDAAD 

DoD  Activity  Address  Directory 

DAAS 

Defense  Automatic  Addressing  System 

MAPAD 

Military  Assistance  Program  Address  Directory 

■H 

LOGDESMAP 

Logistics  Data  Element  Standardization  and  Management 
Program 

1975 

ILCS 

International  Logistics  Communications  System 

1984 

During  this  period  DoD  used  the  increasing  power  of  computers  iuid  telecommu¬ 
nications  to  convert  paper  forms  into  electronic  information.  Each  military  service 
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developed  large-scale  ADP  systems  to  process  its  materiel  management,  depot, 
and  retail  supply  operations.' 

Electronic  communications  also  advanced  significantly  when  the  Automatic 
Digital  Network  (AUTODIN)  was  installed  to  support  worldwide  military  com¬ 
munications  and  the  Defense  Automatic  Addressing  System  (DAAS)  was  estab¬ 
lished  to  perform  the  functions  of  receiving,  validating,  and  routing  transactions  to 
an  addressee  correctly.  The  combined  capabilities  of  logistics  ADP  systems, 
AUTODIN,  and  DAAS  enable  DoD  to  process  nearly  5.5  million  transactions 
each  day  compared  to  only  35,000  daily  transactions  possible  with  paper-based 
procedures.  Figure  2-1  shows  the  scope  of  DLSS  data  flows. 

Figure  2-1.  Overview  of  Defense  Logistics  Standard  Systems  Environment 


The  DLSS  define  primarily  inter-service/agency  procedures  and  formats,  but  the 
military  services  also  adopted  similar  formats  to  manage  their  internal  logistics 
exchanges.  The  DLSS  formats  were  further  extended  for  exchanges  among  DoD, 
General  Services  Administration  (GSA),  and  civil  agencies  through  the  Federal 
Standard  Requisition  and  Issue  Procedures. 

The  DLSS  moved  DoD  to  the  leading  edge  of  technology  and  logistics  manage¬ 
ment  during  the  1960s  and  1970s  and  remain  indispensable  for  logistics 
operations.  Nearly  one  billion  DLSS  transactions  are  exchanged  annually  as  well 
as  a  similar  number  of  related  service  and  agency  transactions. 


'  These  systems  and  their  successors  as  they  have  evolved  are  described  in  DoD  documents  as 
“legacy  systems.”  However,  their  operation  and  communications  are  critical  to  current  and  future 
military  operations. 
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Need  to  Revise  Logistics  Data  Exchanges 


System  Constraints 

The  technology  embodied  in  the  DLSS  and  supporting  ADP  systems  remains  to¬ 
day  about  as  it  was  in  the  1970s.  However,  in  the  intervening  years,  the  capabili¬ 
ties  offered  by  computer  and  telecommunications  technology  have  expanded 
enormously,  as  have  DoD’s  logistics  management  techniques.  That  revolutionary 
growth  has  spurred  increased  demands  for  logistics  data  that  the  fixed-length 
DLSS  transactions  cannot  readily  support.  Four  major  constraints  are  identified  in 
the  following  subsections. 

Inability  to  Support  Additional  Data  Requirements 

The  DLSS  are  composed  of  fixed-length  records  that  generally  use  all  available 
record  positions.  This  feature  inhibits  using  the  standard  DLSS  transactions  to 
support  new  DoD  or  service/agency  initiatives.  This  constraint  reduces  the 
Department’s  ability  to  use  information  to  employ  a  reduced  inventory  posture 
more  effectively. 

To  illustrate  these  limitations.  Table  2-2  depicts  the  DLSS  format  for  the  standard 
DoD  requisition.  The  table  highlights  several  restrictions  in  the  fixed-length  for¬ 
mats,  but  the  fundamental  problem  is  that  most  records  are  saturated  and  cannot 
support  additional  data. 

Table  2-2.  DoD  Standard  Requisition  Data 


Record 

positions 

Field  name 

Restrictions  and  comments 

01-03 

Document  identifier 

More  than  450  various  formats  used  in  the  standard 
transactions;  many  more  used  by  individual  serv¬ 
ices  and  agencies 

04-06 

Routing  identifier  (to 
activity) 

Three-position  code  instead  of  six-position  DoD 
activity  address  code  (DoDAAC)  used  by  key  logis¬ 
tics  participants  to  save  space;  no  space  for  com- 
merciai  identifiers,  such  as  the  data  universal 
numbering  system  (DUNS),  which  has  more  than 
nine  characters 

08-22 

Materiei  identifier 

Supports  national  stock  number,  commercial  and 
government  entity  (CAGE),  and  part  number  but 
does  not  fully  support  additional  identification  of 
nonstandard  materiel 

23-24 

Unit  of  issue 

DoD  codes  that  do  not  support  increasing  use  of 
commerciai  packaging 
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Table  2-2.  DoD  Standard  Requisition  Data  (Continued) 


Record 

positions 

Field  name 

Restrictions  and  comments 

25-29 

Quantity 

Limited  to  five  positions;  uses  codes  for  high 
volume  items,  such  as  ammunition 

30-43 

Requisition  number 

Concatenation  of  DoDAAC,  Julian  date,  and  se¬ 
rial  number 

45-50, 

54-56 

Supplementary  address 
and  distribution 

Does  not  support  in-the-clear  text  addresses  and 
supports  only  a  limited  number  of  distribution 
addresses 

52-53 

Fund  code 

No  line  of  accounting  data  available 

62-64 

Required  delivery  date 

Last  digit  of  year  and  Julian  date;  other  DLSS 
transactions  use  several  different  data  formats; 
DLSS  generally  not  year  2000  (Y2K)-compliant 

65-66 

Advice  code 

Requisitioner’s  requirements  codes;  only  one 
code  supported:  additional  codes  created  for 
combinations,  but  not  all  combinations  support¬ 
able 

07,  44,  51, 

57-61, 

67-80 

Various  codes 

Other  codes  saturate  the  record 

The  limitations  of  the  fixed-length  format  can  be  illustrated  by  using  a  simple  ex¬ 
ample  of  a  shipment  of  100  small  arms  from  a  DoD  depot  to  a  base.  The  DLSS 
transaction  provides  the  stock  number  of  the  weapon,  the  quantity,  the  shipment 
date,  the  shipment  identification  number,  and  other  information.  However,  the 
transaction  does  not  have  the  space  to  identify  the  100  individual  serial  numbers. 
These  numbers  are  provided  separately  by  service-unique  transactions  or  paper. 

Costs  and  iNEFnciENcres  Resulting  from  Unique  Service  and  Agency 
Formats 


The  components’  central  design  agencies  (CDAs)  have  long  recognized  the  DLSS 
limitations  and  have  had  to  design,  program,  and  operate  unique  service  and 
agency  programs  and  transactions  to  meet  evolving  logistics  requirements.  Most 
old  versions  are  DLSS-like  80-character  records  and  are  routed  through  DAAS. 
New  ones  have  frequently  used  diverse  variable-length  formats  that  are  exchanged 
directly  without  any  processing  by  DAAS.  DAAS  processes  more  than  400  differ¬ 
ent  service  and  agency  formats;  the  formats  generate  approximately  100  million 
annual  transactions.  The  number  of  formats  and  transactions  processed  independ¬ 
ent  of  DAAS  is  unknown.  Operating  these  extra  and  redundant  systems  increases 
the  costs  of  DoD’s  logistics  operations.  The  extent  of  these  additional  systems  and 
their  attendant  costs  have  never  been  measured. 
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Constrained  System  Modernization 

Many  legacy  systems  were  developed  contemporaneously  with  the  DLSS,  and 
DLSS  formats  and  codes  are  intertwined  with  the  legacy  systems.  This  factor  has 
and  continues  to  inhibit  modernization  of  these  systems  and  constrains  their 
ability  to  respond  to  new  requirements,  such  as  third-party  logistics. 

DoD  Proprietary  Format 

The  DLSS  are  a  DoD  proprietary  format.  Until  recently  this  condition  has  not 
been  a  significant  problem.  However,  as  DoD  agencies  develop  their  EDI  ex¬ 
changes  with  industry,  the  internal  formats  (DLSS)  will  be  different  than  their 
external  exchanges.  For  example,  the  Defense  Finance  and  Accounting  Service 
(DFAS)  receives  EDI  invoices  from  vendors  and  DLSS  invoices  from  DoD  cus¬ 
tomers.  These  diverse  formats  increase  the  cost  of  supporting  DoD  systems.  As 
DoD  expands  its  reliance  on  industry  trading  partners,  more  commercial  organi¬ 
zations  will  need  to  exchange  logistics  data  with  DoD  activities.  DoD  should  not 
impose  the  limitations  of  the  DLSS  into  these  partnerships,  but  should  use 
commercial  EDI  standards  instead. 


Summary 


The  combined  effects  of  these  constraints  have  produced  disjointed  logistics  ca¬ 
pabilities  and  a  resurgence  of  nonstandard  procedures  and  transactions  by  the 
DoD  components  that  the  DLSS  were  created  to  eliminate.  These  constraints  will 
become  even  more  limiting  when  DoD  is  changing  its  strategy  and  methods  for 
conducting  operations  and  consequently  affecting  logistics  data  requirements. 

Change  in  Environment 

To  meet  these  changing  requirements,  the  Office  of  the  Deputy  Under  Secretary  of 
Defense  (Logistics)  (DUSD[L])  in  its  corporate  strategy  cites  the  following: 

The  emerging  logistics  support  requirement  necessitates  a  significant 
change  in  the  structure  and  delivery  of  material  and  services: 

•  Current  operational  plans  require  support  to  a  joint  fighting  force. 

The  current  threat  requires  a  tailored  and  rapid  response  to  diverse 
operational  requirements.  The  logistics  infrastmcture  must  be 
changed  to  enable  a  significant  reduction  in  decision  cycle  and 
logisties  response  time.. . . 
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•  The  expanded  use  of  commercial  products  and  the  adoption  of 
commercial  processes  to  DoD  business  offers  opportunities  for  en¬ 
hanced  partnerships  with  the  private  sector  to  reduce  the  costs  of  lo¬ 
gistics  support.  Electronic  data  interchange  must  extend  to 
commercial  suppliers  and  the  DoD  infrastructure  must  be  compatible 
with  those  supporting  industry. 

•  The  cost  of  transportation  and  information  technology  has  decreased 
relative  to  the  cost  of  people  and  material.  Levels  of  inventory  and 
maintenance  can  be  eliminated  through  the  use  of  more  timely  and 
accurate  information  and  better  use  of  modern  transportation 
capabilities.^ 

Operating  in  the  new  environment  requires  a  new  approach  to  the  way  logistics  is 
conducted. 

New  Approach  for  Logistics  Systems 

The  overarching  document  for  future  DoD  doctrine  is  the  JCS’s  Joint  Vision 
2010.  This  vision  emphasizes  the  requirement  for  improved  logistics  support  or 
“focused  logistics.” 

Focused  logisties  will  be  the  fusion  of  information,  logistics,  and  trans¬ 
portation  technologies  to  provide  rapid  crisis  response,  to  track  and  shift 
assets  even  while  en  route,  and  to  deliver  tailored  logisties  packages  and 
sustainment  directly  at  the  strategic,  operational,  and  tactical  level  of 
operations.^ 

Focused  logistics  will  be  the  precise  application  of  logistics  and  includes  the 
following  components: 

♦  Rapid  response  and  distribution  of  assets 

♦  Tailored  logistics  packages 

♦  Total  asset  visibility  (TAV)  and  in-transit  visibility  (ITV) 

♦  Reduced  inventory  and  logistics  footprints. 

Joint  Vision  2010  and  focused  logistics  have  led  to  the  development  of  several 
new  concepts,  including  the  Global  Combat  Support  System  (GCSS),  “an  ap¬ 
proach  that  focuses  on  the  development  of  a  common  operating  environment, 
common  data  environment,  and  shared  infrastructure  services  that  enable 


^  Assistcint  Deputy  Under  Secretary  of  Defense  for  Logistics  Business  Systems  and  Technol¬ 
ogy  Development,  Logistics  Business  Systems — Corporate  Strategy,  15  April  1997,  p.  2-1. 

^  Chairman  of  the  Joint  Chiefs  of  Staff,  Joint  Vision  20 JO,  July  1996,  p.  24. 
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interoperability.”^  Publication  of  Joint  Vision  2010  and  the  GCSS  concepts  was 
followed  by  a  series  of  reports  by  the  Office  of  the  Assistant  Deputy  Under  Sec¬ 
retary  of  Defense  for  Logistics  Business  Systems  and  Technology  Develop¬ 
ment,  Defense  Information  Systems  Agency  (DISA),  and  other  DoD  agencies 
that  further  define  the  technical  environment  that  will  compose  GCSS  and  sup¬ 
port  Joint  Vision  2010.  These  documents  identify  the  following  two  requirements: 

♦  DoD  needs  to  use  logistics  information  as  an  asset. 

♦  Although  the  target  logistics  information  system  environment  will  operate 
through  shared  distributed  data,  in  the  interim  DoD  needs  to  exchange  data 
effectively  among  existing  legacy  and  new  systems. 

Figure  2-2,  taken  from  the  Department  of  Defense  Interoperable  Information  En¬ 
vironment,  Concept  of  Operations,  reflects  the  new  concepts  for  shared  and  dis¬ 
tributed  environment  while  also  depicting  the  current  systems  environment.^ 
However,  Figure  2-2  does  not  depict  the  diverse  legacy  systems  linked  by  a  com¬ 
bination  of  the  DLSS  and  service-unique  logistics  transactions.  Figure  2-2  also 
does  not  depict  that  the  DoD  logistics  universe  is  expanding  to  include  an  in¬ 
creasing  number  of  external  participants  and  systems.  The  DLSS  cannot  carry 
DoD’s  new  data  requirements  to  the  next  generation  applications  or  future  target 
environment.  DoD  needs  a  better  alternative. 

Need  for  Better  Data  Exchanges 

Although  the  environment  and  technology  are  changing  dramatically,  in  many 
ways,  the  fundamental  components  of  the  logistics  ADP  environment  have  not 
changed  in  the  more  than  35  years  since  the  inception  of  the  DLSS.  The  DoD 
components  still  operate  separate  inventory  control  point  (ICP)  systems  (the  U.S. 
Coast  Guard,  GS A,  and  others  also  operate  quasi-ICP  systems).  The  Defense  Lo¬ 
gistics  Agency  (DLA)  has  a  standard  distribution  depot  system  and  performs  a 
majority  of  the  depot  operations,  but  the  military  services  also  operate  mainte¬ 
nance  and  other  special  warehousing  and  distribution  systems.  Numerous  retail 
systems  support  units  and  bases.  Further,  the  same  basic  logistics  functions 
(requisitioning,  managing  inventory,  monitoring  materiel  movements,  and  billing) 
still  need  to  be  performed. 


Assistant  Deputy  Under  Secretary  of  Defense  for  Logistics  Business  Systems  and  Teehnol- 
ogy  Development,  Department  of  Defense  Interoperable  Information  Environment,  Concept  of 
Operations,  Glossary,  Acronyms,  and  Abbreviations,  1  August  1997,  p.  2. 

^  Assistant  Deputy  Under  Secretary  of  Defense  for  Logistics  Business  Systems  and  Technol¬ 
ogy  Development,  Department  of  Defense  Interoperable  Information  Environment,  Concept  of 
Operations,  1  August  1997,  p.  16. 
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Figure  2-2.  Interoperable  Information  Environment 


Note:  COE  =  common  operating  environment;  Dll  =  Defense  Information  Infrastructure;  DISN  = 
Defense  Information  System  Network;  DLA  =  Defense  Logistics  Agency;  GDMS  =  Global  Data¬ 
base  Management  System;  JTA  =  Joint  Technical  Architecture;  LAN  =  local  area  network;  LITA  = 
Logistics  Infrastructure  Technical  Architecture;  WAN  =  wide  area  network;  WFN  =  wide  frequency 
network. 

At  the  same  time,  however,  the  logistics  environment  is  changing  dramatically,  as 
evidenced  by  the  following: 

♦  Additional  data  elements  (including  common  DoD-wide  and  unique  ele¬ 
ments  of  the  DoD  components)  associated  with  standard  transactions  that 
the  80-character  records  cannot  accommodate 

♦  Additional  unique  transactions  developed  by  the  military  services  and  de¬ 
fense  agencies  as  workarounds  to  support  new  data  requirements  and 
provide  additional  functionality,  such  as  maintenance  managementDoD 
and  component  logistics  initiatives  (with  their  success  dependent  on  the 
exchange  of  information  between  systems)  that  include  the  following  ex¬ 
amples: 

►  Asset  visibility 

►  Integrated  sustainment 
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►  Lean  (agile)  logistics 

►  On-line  logistics 
Precision  logistics 

►  Prime  vendor 

►  Regional  maintenance 

►  Velocity  management^ 

►  Lateral  redistribution 

►  Serial  number  tracking 

♦  Changing  functional  relationships,  such  as  DLA’s  increased  responsibility 
for  depot  storage  at  both  wholesale  and  retail  levels  (including  DLA’s  in¬ 
creased  management  of  a  military  service’s  assets  and  increased  exchanges 
between  DLA  depots  and  component  ICPs)  and  increased  interservice 
logistics  support  in  maintenance  and  other  areas 

♦  Increased  participation  by  commercial  organizations  within  the  following 
DoD  logistics  activities: 

►  Transportation  services 

►  Direct  vendor  delivery  (DVD)  with  data  exchanges  directly  between  a 
DoD  user  and  supplier  (such  as  the  deliveries  of  subsistence,  medical 
supplies,  and  clothing  directly  to  a  user  that  have  been  arranged  by  the 
Defense  Supply  Center  Philadelphia) 

►  Storage  of  DoD’ s  primary  operating  stocks  and  reserves  (that  are 
maintained  with  commercial  inventories) 

>-  Maintenance  and  repair  services 

►  Disposal  activities 

►  Quality  and  discrepancy  efforts. 

Figure  2-3  reflects  the  expanded  flow  of  data. 

The  DLSS  with  their  80-character  limitation  do  not  support  most  of  the  expanded 
data  flow.  Any  effort  by  DoD  to  impose  the  DLSS  on  industrial  trading  partners 

®  All  items  on  the  list  of  DoD  and  component  initiatives  through  velocity  management  are 
cited  from  Assistant  Deputy  Under  Secretary  of  Defense  for  Logistics  Business  Systems  and  Tech¬ 
nology  Development,  Logistics  Business  Systems — Corporate  Strategy,  15  April  1997,  p.  4-5. 
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would  not  only  contradict  the  federal  policy  for  using  EDI,  but  would  increase  the 
cost  of  operations  by  requiring  contractors  to  maintain  several  systems  and  inter¬ 
face  programs.  The  need  for  better  data  exchanges  can  be  accommodated  by 
implementing  the  Defense  Logistics  Management  System  (DLMS). 

Figure  2-3.  Potential  DoD  and  External  EDI  Flows 


Note:  Procurement  and  transportation-related  EDI  flows  not  included  but  are  equally  involved 

Key:  Materiel  =  - . .  — . ► 

Data  “  ^ 


Implementing  Commercial  EDI  through 
Defense  Logistics  Management  System 

The  DLMS  replaces  the  fixed-length  DoD  proprietary  DLSS  with  the  variable- 
length  ASC  X12  EDI  standards  within  DoD  logistics.  The  ASC  X12  EDI  stan¬ 
dards  offer  a  broad  base  of  business  transactions  to  support  DoD.  The  Defense 
Logistics  Management  Standards  Office  (DLMSO),  the  proponent  of  the  DLMS, 
has  already  completed  a  great  deal  of  the  work  to  prepare  the  DLMS  for  imple¬ 
mentation.  The  functionality  of  more  than  450  DLSS  fixed-length  transaction 
formats  was  consolidated  into  approximately  25  ASC  XI 2  EDI  transaction  sets. 
(See  Appendix  A,  Table  A-1,  for  information  on  the  relationship  of  DLSS  to  ASC 
X12  transaction  sets.)  However,  the  DLMS  is  more  than  a  simple  replacement 
of  the  DLSS.  Working  with  the  military  services  and  defense  agencies, 
DLMSO  included  more  than  100  enhancements  for  additional  data  and  new 
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capabilities  proposed  by  the  services  and  agencies  in  the  DLMS  procedures  and 
transaction  set  formats/  The  DLMS  procedures  and  transaction  set  formats  have 
been  developed  and  documented.  They  are  ready  to  be  implemented.  (See  Appen¬ 
dix  A  for  more  information  on  the  DLMS  program  history). 

Rationale  for  Implementing  EDI  in  DoD 
Logistics 

EDI  has  been  proposed  as  the  replacement  for  the  DLSS  for  several  reasons,  in¬ 
cluding  the  following: 

♦  Support  by  ANSI,  a  neutral  and  independent  national  standards  body  that 
represents  the  full  spectrum  of  U.S.  commerce  and  government.  Further, 
other  ANSI  standards  operations  span  many  ADP  and  other  functions  used 
by  the  government  and  industry. 

♦  Extensive  use  in  industry.  Most  of  America’s  largest  corporations  use  EDI 
in  their  operations. 

♦  Increased  use  in  government,  particularly  in  procurement  and  related 
functions  in  exchanges  with  industry.  DoD’s  EDI  implementation  includes 
the  following  efforts: 

>-  Standard  Procurement  System 

►  DLA’s  prime  vendor  programs  for  subsistence,  medical  supplies,  and 
uniforms 

>-  DFAS’  use  of  commercial  invoices  for  contractor  payments  and 
remittance  advice  provided  with  electronic  funds  transfer* 

►  Progress  payments  by  Defense  Contract  Management  Command 

>-  The  defense  transportation  network’s  extensive  use  of  EDI,  including 
EDI  manifests  from  transportation  sites  and  shipper  EDI  invoices  for 
transportation  services^ 

►  Navy  program  reporting  for  ship  construction 


’  For  a  summary  of  the  enhancements,  see  Logistics  Management  Institute,  Modernization  of 
the  Defense  Logistics  Standard  Systems — Establishing  the  Functional  Baseline,  Volume  I, 
DL902R1,  Donald  F.  Egan,  et  al.,  September  1991. 

^  The  DLMS  version  of  the  Military  Standard  Billing  System  (MILSBILLS)  includes  the  in¬ 
ternal  DoD  invoice  that  uses  the  same  EDI  transaction  set. 

^  The  Transportation  Coordinator’s  Automated  Information  Management  System  II  for  mili¬ 
tary  bases  will  also  use  EDI  extensively. 
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►  Material  safety  data  sheets  used  by  DLA  and  the  Navy’° 

>-  Ordering  and  tracking  of  hazardous  waste  disposal  by  the  Defense 
Reutilization  and  Marketing  Service  (DRMS). 

The  Internet  and  the  World  Wide  Web  represent  an  alternative  approach.  How¬ 
ever,  the  bulk  of  the  DLMS-related  transactions  are  high-volume,  machine-to- 
machine,  routine  business  transactions.  For  these  types  of  transactions,  EDI  is 
more  effective  than  the  Web.''  Nearly  two  billion  DLSS  transactions  are  still  ex¬ 
changed  annually,  and  the  number  of  unique  logistics  transactions  by  the  DoD 
components  may  exceed  that  amount. 

As  DoD  seeks  to  conduct  paperless  acquisition,  why  should  DoD  exchange  pur¬ 
chase  orders,  shipment  notices,  and  invoices  with  industry  by  EDI  while  the  un¬ 
derlying  DoD  requisitions,  dues-in,  and  receipts  use  a  different  format?  DLMS 
implementation  will  introduce  a  standard  approach  used  by  all  systems,  commu¬ 
nications  architectures,  and  technical  staff  members.  This  standard  approach  will 
also  be  consistent  with  exchanges  with  commercial  trading  partners.  Although 
substantial  savings  will  result,  the  very  expanse  of  the  effort  makes  estimating 
savings  difficult.  DLMS  EDI  will  replace  DoD  and  service/agency  proprietary 
standards  with  a  proven  national  standard.  The  DLMS  is  the  means  to  use  a  trans¬ 
action  format  that  is  both  an  industry  and  a  federal  standard  for  intracomponent 
exchanges,  intercomponent  exchanges,  exchanges  among  government  and  com¬ 
mercial  trading  partners,  and  exchanges  among  commercial  organizations 
themselves. 

Will  the  implementation  of  EDI  save  money?  Yes.  However,  the  most  extensive 
savings  in  adopting  EDI  or  electronic  commerce  (EC)  are  obtained  by  converting 
paper  forms  and  manual  processes  to  automated  transactions.  The  DLSS  already 
accomplished  those  savings.  Converting  from  one  electronic  format  to  another 
will  not  redouble  the  savings.  Nonetheless,  savings  will  accrue  by  reducing  ADP 
programming  and  support  costs  caused  by  the  myriad  of  the  DoD  compo¬ 
nents’  unique  programs,  formats,  and  communications  used  to  bypass  DLSS 
inadequacies. 

The  DLMS  will  also  promote  future  modernization  efforts  by  separating  the  for¬ 
mat  of  data  exchanges  from  the  application  systems  themselves.  One  great  diffi¬ 
culty  in  modernizing  the  many  DoD  logistics  systems  has  been  that  DLSS  data 
and  transaction  formats  are  embedded  in  program  code.  The  impact  of  this 


This  report  retains  the  Navy’s  preferred  spelling  of  “material”  for  material  safety  data  sheets 
and  Navy  programs  but  uses  the  prevalent  spelling  of  “materiel”  in  other  contexts. 

"  Some  critics  of  DoD’ s  adoption  of  EDI  cite  that  most  current  corporate  implementations  use 
the  Web,  not  EDI.  However,  most  large  corporations  have  already  implemented  EDI  in  key  inter¬ 
company  logistics  functions  and  are  now  implementing  the  Web  for  customer  sales  and  support 
and  other  machine-to-human  functions.  Also  note  that  the  Internet  as  a  telecommunications  path, 
not  the  Web,  is  being  used  increasingly  to  exchange  XI 2  EDI  data. 
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difficulty  was  realized  recently  when  DoD  evaluated  the  cost  of  converting 
organizational  identifications  from  DoDAACs  and  CAGE  codes  to  the  DUNS. 
Establishing  a  DoD  data  exchange  transaction  format  that  can  be  separated  from 
the  application  systems  will  allow  these  systems  to  evolve  freely  to  support  new 
functionality  and  technologies.  The  separation  of  data  exchange  formats  from  the 
legacy  application  systems  is  one  of  the  DII  principles  and  COE  requirements  for 
data  independence. 

Benefits 

The  effective  use  of  logistics  data  is  critical  to  the  success  of  focused  logistics  and 
similar  initiatives.  The  DLSS  cannot  deliver  the  data;  commercial  EDI  standards 
can.  Implementation  will  provide  improvements  in  the  following  areas: 

♦  Data  to  support  functional  initiatives 

♦  Reliance  on  commercial  standards  and  industry  participation 

♦  Technology  goals. 

Data  to  Support  Functional  Initiatives 

DLSS  transactions  do  not  support  an  extensive  list  of  data  elements,  such  as  serial 
numbers,  weapon  systems  identification,  DUNS,  additional  nonstandard  identifi¬ 
cation  numbers,  multiple  advice  codes,  linkage  of  requisitions  to  transportation 
control  numbers  (TCNs),  and  linkage  of  military  TCNs  to  commercial  shipment 
identifications.  These  data  elements  and  others  are  needed  for  serial  number 
tracking,  TAV,  and  initiatives  that  create  lean  and  focused  logistics.  DoD’s 
35-year-old  fixed-length  standards  are  data-saturated  and  no  longer  viable.  The 
DLSS  also  do  not  support  several  existing  procedures  that  are  still  paper-based  or 
operated  by  component  systems,  including  maintenance,  discrepancy  reporting, 
and  small  arms  tracking.  The  DLMS  EDI  variable-length  formats  meet  DoD’s 
current  data  requirements  and  have  the  flexibility  to  meet  future  requirements  as 
well. 
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Reliance  on  Commercial  Standards  and  Industry  Participation 

Several  DoD  documents  indicate  the  future  will  require  greater  participation  by 
commercial  partners.  The  following  quotation  from  an  OSD  strategy  document  is 
an  example: 

The  logistics  information  systems  will  act  collectively  as  a  global  sys¬ 
tem,  reaching  from  the  battlefield  to  a  sustaining  base  that  includes  in¬ 
dustry.  The  expanded  use  of  commercial  products  affords  DoD  an 
opportunity  to  acquire  parts  and  services  from  the  open  market,  obtain 
support  directly  from  a  manufacturer,  as  well  as  third-party  support  ar¬ 
rangements.  The  adaptation  of  commercial  practices,  including  the  use 
of  commercial  data  standards,  enables  electronic  transactions  with  in¬ 
dustry  and  vendors.  For  example,  the  adoption  of  EDI  standards  (ANSI 
XI 2)  greatly  enhances  DoD’s  ability  to  integrate  with  industry  and  can 
contribute  to  a  reduction  in  logistics  response  time  and  life-cycle  cost.*^ 

ICPs  and  contracting  offices  should  not  use  EC  and  EDI  to  solicit  and  order  while 
the  supporting  requisition  and  the  materiel  due-in  information  are  in  a  DoD  pro¬ 
prietary  format.  DFAS  should  not  receive  invoices  from  and  provide  remittance 
advice  to  vendors  in  EDI  while  DoD  receipts  and  intra-DoD  invoices  are  in  DoD 
proprietary  formats.  Transportation  programs  are  operating  with  both  DoD  mani¬ 
fest  formats  and  commercial  manifests.  DoD  is  paying  a  high  cost  to  operate  in 
EC  and  EDI  externally  and  the  DLSS  internally.  This  cost  is  further  increased  by 
the  various  unique  component  formats. 

Industry  has  been  using  the  ASC  XI 2  standards  for  20  years  in  exchanging  pur¬ 
chase  orders,  shipment  notices,  invoices,  and  many  other  transactions  electroni¬ 
cally.  Over  the  last  decade  the  federal  government  has  also  been  adopting  these 
standards,  particularly  in  exchanges  with  industry.  This  commitment  has  been 
demonstrated  in  presidential  memoranda  regarding  EDI  and  EC  in  October  1994 
and  July  1997,  by  Congress  in  the  Federal  Acquisition  Streamlining  Legislation 
Act  of  1994,  and  through  federal  standards,  such  as  Federal  Information  Process¬ 
ing  Standard  (FIPS)  161-2,  Electronic  Data  Interchange. 

As  DoD  moves  increasingly  towards  industry  support  of  traditional  DoD  activi¬ 
ties,  such  as  inventory  management  and  weapons  systems  maintenance,  industry 
needs  to  participate  in  DoD  data  exchanges.  EDI  will  provide  a  bridge  between 
DoD  logistics  systems  and  contractor  software  that  allows  them  to  function  to¬ 
gether.  DLMS  EDI  replaces  DoD  proprietary  standards  with  commercial  ASC 
X12  standards.  It  unifies  diverse  organizations,  procedures,  policies,  ADP  sys¬ 
tems,  and  technologies.  It  integrates  DoD’s  internal  logistics  exchanges  into  the 
same  standards  that  industry  uses. 


Assistant  Deputy  Under  Secretary  of  Defense  for  Logistics  Business  Systems  and 
Technology  Development,  Logistics  Business  Systems — Corporate  Strategy,  15  April  1997,  p.  3-2. 
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Need  to  Revise  Logistics  Data  Exchanges 


DoD  Technology  Goals 

In  the  last  few  years  the  Joint  Chiefs  of  Staff,  DISA,  and  DUSD(L)  have  proposed 
through  the  GCSS  a  technical  architecture  that  will  unify  diverse  legacy  systems 
and  combine  them  with  newer  systems  to  provide  information  across  the  logistics 
spectrum.  The  technical  architecture  and  underlying  systems  will  manage  and  ex¬ 
change  data  to  use  information  as  a  corporate  asset  to  achieve  DoD  initiatives 
such  as  focused  logistics  and  total  asset  visibility. 

Key  to  this  effort  is  moving  standard  data  between  systems  and  users.  The  DLMS 
procedures  define  the  interservice  logistics  data  elements  and  rules  for  their  ex¬ 
change.  The  DLMS  EDI  transaction  sets  define  the  formats  for  their  movement. 
EDI  translation  software  provides  both  component  legacy  systems  and  participat¬ 
ing  contractor  systems  with  data  independence  that  allows  them  freedom  of  hard¬ 
ware  and  software  platforms,  supports  internal  business  practices,  and  provides 
the  ability  to  modernize  systems. 

Summary 

The  disjointed  logistics  capabilities  and  resurgence  of  nonstandard  procedures  and 
transactions  illustrate  the  need  for  better  data  exchanges.  The  DLMS  meets  the 
requirements  for  additional  data  and  new  capabilities  needed  by  the  military  serv¬ 
ices  and  defense  agencies.  The  next  chapter  identifies  organizational  roles  and 
responsibilities  to  implement  the  DLMS. 


2-15 


Chapter  3 

EDI  Implementation — Organizational  Roles  and 
Responsibilities 


This  chapter  defines  the  roles  and  responsibilities  of  several  organizations  that  are 
instrumental  in  implementing  DLMS.  They  include  the  Joint  Electronic  Com¬ 
merce  Project  Office  (JECPO),  DLMSO,  DISA,  DAAS  Center  (DAASC),  and 
DLMS  users.  It  also  identifies  basic  principles  and  objectives  to  guide  implemen¬ 
tation  planning. 

Participating  Organizations 

JECPO 

The  JECPO  is  responsible  for  accelerating  the  application  of  electronic  business 
practices  and  associated  information  technologies  to  improve  DoD  acquisition 
processes.  It  includes  members  of  DISA,  DLA,  and  the  Life-Cycle  Information 
Integration  Office.  Because  DLMS  is  a  major  EC  implementation  that  inte¬ 
grates  internal  and  external  DoD  data  exchanges,  DLMSO  is  one  of  the  DLA 
components  of  the  JECPO  organization. 

DLMSO 


DLMSO  is  the  primary  proponent  of  the  DLMS.  It  operates  under  the  authority  of 
DoD  Directive  4140.1,  Materiel  Management  Policy.  DLMSO’s  support  of 
logistics  data  exchange  includes  the  following  functions: 

♦  Maintain  procedures  for  logistics  operations  among  the  DoD  components. 
Previously,  these  procedures  have  been  MILSTRIP  and  related  military 
standard  (MILS)  procedures.  They  have  been  combined  for  the  DLMS  into 
a  single  manual,  DoD  4000.25 -M,  Defense  Logistics  Management  System, 
which  consists  of  several  volumes.^  The  variable-length  formats  have  al¬ 
ways  been  the  primary  focus  in  developing  the  DLMS,  but  the  procedures 
and  the  components’  commitment  to  a  joint  process  are  equally  important. 


‘  U.S.  Department  of  Defense,  Defense  Logistics  Management  System,  DoD  4000.25-M,  Ver¬ 
sion  2.0,  December  1995. 
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♦  Maintain  the  DLMS  implementation  conventions  (ICs)}  Approximately 
55  ICs  are  ready  to  be  implemented.  They  will  require  revision  to  support 
evolving  DoD  logistics  requirements.  The  DoD  components  provide  most 
requests  for  IC  changes.  DLMSO  coordinates  changes  through  the  process 
review  committees  (PRCs)  and  with  federal  EDI  standards  committees.  In 
addition,  DLMSO  coordinates  changes  through  ASC  XI 2  when  the  basic 
standards  require  changes.  The  ICs  are  documented  in  the  DLMS  manual 
and  are  an  integral  part  of  it.^ 

♦  Chair  PRCs.  DLMSO  hosts  the  PRCs  that  consist  of  representatives  from 
each  DoD  component  and  participating  civil  agencies.  A  PRC  is  estab¬ 
lished  for  each  DLMS  functional  area  (such  as  supply,  transportation, 
and  finance).  The  PRCs  are  the  committees  that  manage  the  DLMS 
functionality. 

♦  Coordinate  with  other  government  organizations.  This  action  includes 
representing  the  DLMS  and  logistics  data  requirements  of  the  DoD  com¬ 
ponents  to  OSD,  DISA,  DAASC,  the  Federal  EDI  Standards  Management 
Coordinating  Committee  and  its  Logistics  Functional  Working  Group,  and 
other  organizations. 

DISA 

DISA  plays  a  pivotal  role  in  the  federal  and  DoD  EC  architecture.  As  part  of  its 
responsibilities,  DISA 

♦  leads  technical  architecture  management, 

♦  coordinates  standards, 

♦  leads  development  of  technical  solutions  and  alternatives, 

♦  develops  enterprise  licensing  approaches, 

♦  conducts  testing, 

♦  coordinates  technical  cross-functional  integration,  and 

♦  conducts  systems  engineering. 


^  X12  EDI  transaction  sets,  such  as  the  51 1  requisition,  are  generic  and  available  for  use  by 
anyone.  An  IC  documents  the  use  of  the  transaction  set  by  a  trading  partner  community  (in  this 
case,  the  DLMS  community).  An  IC  defines  data  elements,  their  format,  and  content.  The  ICs  are 
the  keys  to  DLMS  documentation. 

^  In  addition  to  the  ICs,  DoD  4000.25-M  contains  information  to  assist  in  the  conversion  from 
DLSS  to  DLMS.  This  chapter  discusses  ICs  because  they  have  a  critical  role  in  documenting  the 
transmission  format  and  conversion  issues. 


3-2 


EDI  Implementation — Organizational  Roles  and  Responsibilities 


For  DLMS  operations,  DISA  will  provide  the  majority  of  the  telecommunications 
infrastructure.  DISA  will  provide  connectivity  through  its  electronic  commerce 
processing  nodes  (ECPNs)  to  civil  agencies  and  contractors  (and  their  conunercial 
value-added  networks  [VANs])  as  needed.'* 


DAASC 


DAASC  will  continue  to  be  the  center  for  DLMS  transaction  flow  and  conduct  its 
traditional  logistics  information  support  functions.  DAASC  will  be  the  initial 
recipient  of  most  DLMS  transactions  and  will 

♦  provide  retrieval,  reporting,  and  archiving  services  by  collecting  data  into 
the  Logistics  Information  Processing  System  (LIPS)  and  other  long-term 
storage  media; 

♦  route  and  distribute  original  transaction  sets  and  copies  as  requested  by 
users  and  required  by  DoD  policy; 

♦  route  transaction  sets  to  special  databases,  such  as  the  Global 
Transportation  Network; 

♦  edit  and  validate  transaction  sets; 

♦  perform  specialized  capabilities,  such  as  coordinating  the  Defense 
Program  for  Redistribution  of  Assets; 

♦  support  EDI  translation  capabilities  for  selected  users;  and 

♦  chair  the  DLMS  Technical  Review  Committee  (TRC). 

During  the  migration  period  when  some  activities  have  not  implemented  DLMS, 
DAASC  will  also  provide  a  conversion  capability  between  those  activities  and  the 
ones  that  have  implemented  DLMS. 

DLMS  Users 

The  basic  DLMS  functions  will  differ  very  little  from  the  DLSS  environment.  Us¬ 
ers  need  to  follow  DLMS  procedures  for  interservice  functions  and  application 
system  data. 

The  user  community  needs  to  be  very  active  in  DLMS  implementation  planning 
and  execution.  Further,  DLMS  users  need  to  participate  continually  in  the  PRCs 
and  TRC  to  ensure  that  their  and  other  systems  evolve  with  changing  DoD  logis¬ 
tics  requirements.  This  process  was  once  very  proactive,  but  has  attenuated 


VANs  are  companies  that  provide  standard  EDI  interconnection  services  between  firms  op¬ 
erating  EDI.  VANs,  DAASC,  and  DISA  ECPNs  perform  some  similar  functions. 
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recently  during  the  effort  to  build  corporate  information  systems  and  independent 
service  modernization  efforts.  This  process  needs  to  be  restored  to  its  previous 
level  of  cooperative  participation. 

Implementation  Objective,  Principles, 

AND  Goals 

Business  Objective 

The  objective  is  to  implement  DLMS  EDI  throughout  the  DoD,  participating  civil 
agencies,  and  logistics  contractors.  This  implementation  will  be  in  support  of  core 
logistics  functions,  new  logistics  initiatives,  and  efforts  to  reduce  unique  service 
programming  developed  to  bypass  DLSS  limitations. 

Core  Principles 

DLMS  implementation  will  be 

♦  guided  by  recommendations  from  participants  (including  functional  and 
technical  experts;  retail,  wholesale,  finance,  and  transportation  specialists; 
and  all  users,  including  military  services,  defense  agencies,  joint  com¬ 
mands,  civil  agencies,  and  contractors)  at  all  levels; 

♦  functionally  driven  and  supported  by  valid  business  needs; 

♦  process-  and  time-phased  to  minimize  disruption  of  customer  systems  and 
benefit  from  the  lessons  learned  during  a  previous  phase; 

♦  forward-looking^;  and 

♦  compliant  and  integrated  with  other  federal  EDI  implementation  efforts 
and  technical  EDI  architectures  of  DoD  and  its  components. 


Goals 


The  implementation  effort  will  focus  on  the  following  goals: 

♦  Establish  (or  revitalize  previous)  joint  working  groups  to  oversee  planning 
and  implementation. 


’  DLMS  will  discard  outdated  DLSS  processes,  transaction  types,  and  codes  where  possible 
and  incorporate  new  user  requirements  and  data. 
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♦  Develop  an  implementation  plan  to  accomplish  at  least  the  following 

actions: 

>■  Process  enhanced  data  in  standard  transactions. 

►  Incorporate  data  and  transactions  of  the  DoD  components  into  standard 
transaction  sets. 

►  Support  new  DoD  logistics  initiatives. 

»  Expand  into  maintenance  and  other  areas  as  appropriate. 

►  Eliminate  DLSS  codes  and  transactions  that  provide  minimal 
functionality. 

♦  Document  a  phased  approach  for  implementation  and  incorporate  a 

milestone  schedule. 

♦  Monitor  and  manage  the  implementation. 

Summary 

JECPO,  DLMSO,  DISA,  and  DAASC  have  major  roles  and  responsibilities  for 
implementing  the  DLMS.  However,  they  are  service  providers  and  joint  facilita¬ 
tors  and  coordinators.  The  logistics  users  within  the  JCS,  military  services,  de¬ 
fense  agencies,  and  civil  agencies  have  the  primary  responsibility  for  determining 
DLMS  functionality  and  supporting  its  capabilities  by  modifying  their  legacy 
systems  and  service  procedures  to  reflect  interservice  standards.  Those  organi¬ 
zations  need  to  develop  and  execute  a  strategy  to  migrate  the  DLSS  to  DLMS  and 
EDI  as  described  in  the  following  chapter. 
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Chapter  4 

Migration  Strategy 


The  DLSS  data  and  transaction  formats  are  embedded  into  the  program  code  and 
structure  of  hundreds  of  DoD  logistics  computer  programs  and  databases  that 
support  supply,  transportation,  finance,  and  other  operations  used  by  wholesale 
and  retail  activities.  These  transaction  formats  are  in  programs  that  are  decades 
old  and  have  even  been  propagated  into  newer  or  revised  systems.  Although  the 
effort  to  change  these  systems  seems  daunting,  the  alternative  of  status  quo  is  not 
acceptable.  An  ever  diverging  set  of  systems  in  the  DoD  components  tied  loosely 
together  by  35-year-old  standards  and  massive  data  conversions  is  not  acceptable. 
This  set  hinders  and  makes  implementing  new  cross-component  initiatives,  devel¬ 
oping  new  systems,  and  moving  to  DoD’s  target  data  architecture  very  costly. 

The  strategy  to  migrate  from  DLSS  to  EDI  needs  to  contain  the  following  three 
major  components: 

♦  Map  the  application  system  input  and  output  routines  to  the  new  formats.^ 

♦  Expand  or  integrate  the  functionality  of  the  application  systems  and  related 
procedures  to  support  new  functionalities  such  as  unique  item  tracking,  as¬ 
set  visibility  tracking,  and  interservice  and  outsourced  maintenance. 

♦  Consolidate  unique  data  and  transactions  into  the  EDI  formats  and 
eliminate  redundant  processes. 

Because  the  migration  effort  will  be  a  significant  challenge,  it  needs  to  be  care¬ 
fully  coordinated  and  implemented  in  phases.  It  also  needs  to  be  managed  jointly 
because  it  affects  all  DoD  organizations  and  systems. 

Migration  Planning  and  Organization 

The  breadth  of  DLMS  implementation  requires  an  organization  that  represents  the 
DoD  components  to  coordinate  and  direct  implementation.  The  following  DLMS 


'  Mapping  will  need  to  be  performed  in  an  extensive  number  of  systems,  but  is  fairly  routine. 
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stakeholders  need  to  participate  in  planning  implementation  actions  and 
coordinating  their  execution: 

♦  Military  services  and  defense  agencies,  including  DLA,  DFAS,  and  the 
National  Security  Agency 

♦  Joint  commands,  including  the  JCS,  U.S.  Transportation  Command,  and 
other  unified  and  specified  commands 

♦  Major  civil  agencies,  including 

►  GSA, 

►  National  Imagery  and  Mapping  Agency  (NIMA), 

►  U.S.  Coast  Guard, 

►  Federal  Aviation  Administration,  and 
>-  Veterans  Administration 

♦  Supporting  organizations,  including 
^  DUSD(L), 

^  DISA, 

JECPO, 

^  DLMSO, 

»  DAASC,  and 

►  Defense  Logistics  Information  Service  (DLIS)  (formerly  Defense 
Logistics  Services  Center). 

Representation  from  these  organizations  should  include  ICPs,  depot  operations, 
retail  operations,  and  technical  support.  Implementation  planning  needs  to  include 
both  functional  and  technical  aspects.  To  develop  the  initial  DLMS  transaction 
sets,  OSD  and  DLMSO  requested  the  formation  of  DLMS  functional  and  techni¬ 
cal  working  groups.  These  groups  are  needed  to  establish  an  implementation  plan 
and  related  documents  that  include  the  following  key  actions: 

♦  Develop  a  phased  implementation  approach,  including  the  means  to  oper¬ 
ate  in  a  combined  DLSS  and  DLMS  environment  for  a  transition  period. 

♦  Develop  a  milestone  schedule. 
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♦  Develop  a  test  plan. 

♦  Monitor  and  manage  the  actual  implementation,  including  identification 
and  resolution  of  new  issues  and  problems  and  distribution  of  information 
to  key  programming  groups. 

♦  Identify  and  incorporate  new  logistics  initiatives  and  determine  the  timing 
and  mechanism  for  implementing  enhancements  already  identified. 

♦  Expand  into  maintenance  and  other  areas  as  appropriate. 

♦  Eliminate  DLSS  codes  and  transactions  that  provide  minimal 
functionality. 

♦  Review  unique  transactions  of  the  DoD  components  and  perform 
incorporation  or  conversion  actions. 

One  of  the  most  complex  tasks  is  to  determine  the  phasing  of  implementation. 

The  following  section  addresses  this  task. 

Phased  Approach 

Because  the  DLMS  implementation  effort  will  be  a  major  undertaking,  a  phased 
approach  is  recommended.  The  planning  group  will  need  to  determine  the  order 
and  methods  for  implementation.  One  possible  approach  is  to  begin  implementa¬ 
tion  with  a  limited  set  of  trading  partners  and  expand  gradually  to  include  ex¬ 
changes  with  greater  volumes  and  more  systems  and  activities.  This  approach 
minimizes  risk,  provides  an  opportunity  to  apply  lessons  learned  to  the  next  phase, 
and  provides  more  planning  time  for  the  diverse  retail  systems.  The  following 
phases  illustrate  this  approach: 

♦  Third-party  logistics  operations  and  special  projects,  such  as  those  that 
involve  ICPs  and  contractors 

♦  Inventory  management  exchanges  between  ICPs  and  distribution  depots, 
exchanges  between  these  organizations  and  the  DoD  transportation 
network,  and  additional  exchanges  to  incorporate  maintenance 

♦  Retail  logistics  and  finance  systems  (including  those  operated  by  DFAS) 

♦  Discrepancy  reporting 

♦  Consolidation  of  unique  data  and  transactions  of  the  DoD  components. 

Figure  4-1  illustrates  the  inclusion  of  systems  and  activities  in  a  phased  expansion 
of  the  DLMS.  Implementing  DLMS/i>j:t  with  third-party  logistics  support 
contractors  eliminates  the  need  to  establish  and  support  software  of  a  DoD 
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component  in  the  commercial  trading  partner  sites.  This  step  also  maintains  the 
federal  policy  of  using  EDI  as  the  single  face  to  industry  and  supports  the  open 
systems  concept  of  allowing  the  commercial  trading  partners  to  use  their  own 
systems  and  exchange  standard  data  in  standard  formats.  In  concert  with  this  ef¬ 
fort,  special  programs  (including  a  few  DoD  trading  partner  communities,  such  as 
foreign  military  sales  programs)  can  also  begin  DLMS  implementation.  Any  new 
program  should  be  developed  using  DLMS  as  the  basis  of  transaction  exchange. 

Figure  4-1.  Phased  Expansion  of  Defense  Logistics  Management  System  and  EDI 


A  second  phase — one  that  can  quickly  follow  the  first  phase — extends  the  ICP 
exchange  capabilities  to  DLMS  exchanges  with  distribution  depots.  DLMS  ex¬ 
changes  can  also  be  linked  to  the  transportation  data  network.  Lastly,  in  this  step, 
DLMS  exchanges  can  be  linked  to  maintenance  depots,  creating  a  functionality 
that  does  not  exist  in  the  DLSS. 
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Implementing  the  large  and  diverse  mix  of  retail  and  finance  systems  and  their 
exchanges  of  requisition  and  retail  inventory  information  as  the  third  phase  pro¬ 
vides  extended  planning  time  for  the  central  design  agencies  (CD  As)  to  prepare 
for  implementation.  This  phase  also  provides  an  opportunity  to  apply  lessons 
learned  from  the  previous  two  phases.  The  next  phase  can  incorporate  the 
complex,  but  low-volume,  exchanges  of  discrepancy  reporting  and  contract 
management.  The  final  phase  can  be  a  consolidation  of  unique  service  transac¬ 
tions  into  the  DLMS  or  related  EDI  transactions.  Much  of  this  consolidation 
will  occur  in  earlier  phases.  This  step  should  eliminate  a  considerable  body  of 
programming  code  and  effort  by  CD  As. 

A  phased  approach  initiates  the  effort  with  a  few  systems  and  CD  As  and  increases 
the  number  of  participants  only  as  experience  is  gained.  This  approach  minimizes 
risk,  while  still  completing  implementation  in  a  reasonable  amount  of  time.  How¬ 
ever,  other  approaches  may  also  offer  advantages  and  should  be  considered  by  the 
planning  organization. 
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Chapter  5 

Cost  and  Benefits  Summary 


A  classic  cost-benefit  analysis  measures  the  annual  cost  of  doing  business  in  the 
current  environment,  estimates  the  investment  cost  to  develop  the  replacement 
system,  and  estimates  the  annual  cost  of  operating  in  the  new  environment.  How¬ 
ever,  developing  a  reliable  and  comprehensive  functional  economic  analysis  for 
implementing  DLMS  is  not  cost-effective  because  of  several  factors.  The  factors 
include  the  extensive  scope  of  defense  logistics  data  exchanges;  the  entangled  de¬ 
velopment  of  exchange  formats  with  legacy  systems;  the  obscure  costs  associated 
with  inadequate  solutions,  redundancies,  and  inefficiencies  in  dealing  with  the 
DLSS;  and  the  lack  of  metrics.  However,  several  general  measurements  allow  us 
to  establish  a  framework  for  estimating  the  investment  cost  and  benefits. 

Implementation  Cost  Estimate 

In  the  early  1990s  the  Joint  Logistics  Systems  Center  (JLSC)  was  assigned  the 
task  of  developing  a  single  standard  wholesale  materiel  management  (or  ICP) 
system  as  well  as  a  single  depot  maintenance  system.  In  addition,  the  JLSC  coor¬ 
dinated  similar  endeavors  for  standard  distribution  and  transportation  systems. 

The  JLSC  effort  also  included  incorporating  the  DLMS  into  the  standard  systems. 
Although  this  task  was  not  completed,  JLSC  developed  a  planning  document 
in  1995  that  provided  a  cost  and  time  estimate  for  implementing  DLMS  in  its 
scope  of  operations.^ 

The  JLSC  estimate  for  EDI  implementation  included  the  standard  materiel  man¬ 
agement  system,  standard  depot  maintenance  system,  distribution  standard  sys¬ 
tem,  and  joint  transportation  systems.  The  JLSC  study  used  industry  averages  for 
each  implemented  transaction  set  and  resulted  in  the  estimate  of  $16.6  million  in 
Table  5-1. 

We  used  the  JLSC  estimate  as  a  framework  for  projecting  the  DLMS  implemen¬ 
tation  cost.  We  updated  the  estimate  to  account  for  the  continued  presence  of  sev¬ 
eral  service  legacy  systems  (rather  than  the  JLSC-intended  single  standard 
system);  functions  (e.g.,  retail  systems  and  DFAS)  not  included  in  the  JLSC  study; 
and  inflation. 


’  Defense  Information  Systems  Agency,  Center  for  Integration  and  Interoperability  Electronic 
Data  Systems  (prepared  by  Electronic  Data  Systems,  Inc.),  MODELS  Implementation  Plan,  two 
volumes,  24  January  1995.  See  Volume  I,  p.  11-19,  and  Volume  II,  Chapter  7,  Cost  and  Schedule, 
pp.  11-48  to  11-61. 
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Table  5-1.  JLSC  Cost  Estimate  ($  million) 


Description 

Estimate 

Materiel  management  system 

3.8 

Depot  maintenance  system 

2.9 

Distribution  standard  system 

2.0 

Joint  transportation  systems 

1.1 

Infrastructure 

4.0 

Program-level  coordination 

2.4 

Training  and  education 

0.4 

Total 

16.6 

The  first  column  of  Table  5-2  displays  the  functional  areas  of  the  JLSC  estimate. 
The  second  column  provides  a  revised  estimate  using  1999  values  to  account  for 
inflation.  The  third  column  provides  the  baseline  estimate  for  implementing  EDI 
in  logistics. 


Table  5-2.  Implementation  Cost  Estimate  ($  million) 


Description  (functional  area) 

Revised  JLSC  esti¬ 
mate  (1 999  dollars) 

Baseline 
logistics  EDI 
estimate 

Materiel  management  systems 

4.4 

- 

Component  legacy  systems 

- 

25.0 

Special  systems 

15.0 

Retail  systems 

40,0 

Depot  maintenance  system 

3.4 

15.0 

Distribution  standard  system 

2.4 

3.0 

Joint  transportation  systems 

1.3 

2.0 

Infrastructure 

4.6 

5.0 

Program-level  coordination 

2.8 

3.0 

Training  and  education 

0.5 

2.0 

Allocation  for  exigent  changes  and  costs 

15.0 

Total 

19.4 

125.0 

The  following  considerations  were  used  to  develop  the  baseline  DLMS  estimate: 

♦  Materiel  management  systems.  In  addition  to  the  primary  materiel  man¬ 
agement  systems  of  the  DoD  components,  special  and  retail  systems  need 
to  be  revised  to  implement  DLMS. 

»  Primary  component  legacy  systems.  JLSC  envisioned  only  one  mate¬ 
riel  management  (or  ICP)  system.  However,  we  need  to  plan  for  the 
separate  systems  that  support  the  five  military  and  one  DLA  ICP  sys¬ 
tems.  Using  the  adjusted  estimate  of  $5  million  for  a  primary  legacy 
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system,  we  estimate  the  implementation  cost  to  be  $25  million  for  all 
five  organizations. 

►  Special  systems.  These  systems  were  not  included  in  the  JLSC  study 
and  include  systems  operated  by  DFAS,  DRMS,  DLIS,  and  10  small 
ICPs  (including  NIMA  and  Defense  Automated  Printing  Service).  Es¬ 
timating  an  average  cost  of  approximately  $1  million,  the  imple¬ 
mentation  cost  of  these  special  systems  is  $15  million  ($40  million 
cumulative). 

►  Retail  systems.  Retail  systems  were  outside  the  JLSC  scope.  Each 
service  and  agency  operates  one  and  sometimes  more  than  one  retail- 
level  (e.g.,  base,  unit,  and  ship)  system.  These  systems  are  usually 
less  complex  than  ICP  systems,  but  are  far  more  numerous.  We  esti¬ 
mate  the  implementation  cost  for  the  military  services  and  DLA  to  be 
approximately  $40  million  ($80  million  cumulative). 

♦  Depot  maintenance  systems.  Similar  to  the  JLSC’s  estimate  for  ICP  sys¬ 
tems,  JLSC  envisioned  only  one  maintenance  system.  However,  the  mili¬ 
tary  services  are  maintaining  separate  systems.  With  an  estimate  of 
$3.5  million  for  each  military  service,  we  estimate  the  cost  for  the  four 
military  services  to  be  $15  million  ($95  million  cumulative). 

♦  Distribution  standard  system  and  joint  transportation  systems.  The  origi¬ 
nal  JLSC  estimate  was  $3.1  million.  As  these  functional  areas  are  still 
consistent  with  the  JLSC  estimate,  we  adjusted  them  only  for  inflation  and 
increases  in  the  scope  and  functionality  of  the  systems  to  a  combined  cost 
of  $5  million  ($100  million  cumulative). 

♦  Infrastructure,  program-level  coordination,  and  training  and  education. 
These  elements  include  capital  improvements,  programming,  and  software 
for  DISA,  DAASC,  and  other  DoD  components  as  well  as  DoD  coordina¬ 
tion  and  training.  As  we  are  estimating  a  scope  greater  than  the  limited 
area  JLSC  envisioned,  we  estimate  $10  million  for  these  areas 

($110  million  cumulative). 

As  a  result,  we  estimate  a  cumulative  cost  of  $1 10  million  for  updating  DoD’s 
logistics  data  infrastructure  to  achieve  Joint  Vision  2010.  EDI  implementation 
will  require  between  3  to  5  years.  Hence,  to  allow  for  additional  inflation  and  in¬ 
clude  a  safety  net  for  unforeseen  costs,  we  estimate  a  total  cost  of  approximately 
$125  million.  This  estimate  includes  system  revisions  to  exchange  EDI  for¬ 
mats  and  basic  enhancements,  such  as  expanded  field  sizes,  standard  dates,  and 
transmission  of  data  that  already  exist  in  service  and  agency  systems.  The  estimate 
does  not  address  coordinating  and  implementing  major  initiatives,  such  as  com¬ 
plete  serial  number  tracking  that  is  generally  not  present  in  the  large  service  and 
agency  logistics  systems. 
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Benehts 

Measurable  Benefits 

Identifying  opportunities  for  EDI  implementation  in  DoD  logistics  functions  is  not 
difficult;  however,  as  with  costs,  quantifying  the  savings  of  opportunities  is  diffi¬ 
cult.  This  difficulty  is  complicated  because  most  EC  savings  are  derived  by  con¬ 
verting  data  exchanges  from  paper  to  electronic  processing.  However,  the  DLMS 
effort  generally  involves  converting  from  one  electronic  means  to  another,  al¬ 
though  several  exceptions  exist  and  are  discussed  in  the  following  subsections  that 
identify  areas  where  EDI  implementation  can  reduce  operating  costs. 

Exception  Requisitions 

Most  requisitions  are  for  standard  items  in  the  DoD  inventory;  specifying  the  na¬ 
tional  stock  number  in  the  DLSS  requisition  is  the  only  information  needed  to 
identify  the  materiel.  However,  sometimes  an  unusual  item  or  one  no  longer  in  the 
inventory  is  required.  These  cases  require  submitting  a  DLSS  nonstandard  item 
requisition  followed  by  paper  documentation  fully  identifying  the  item  character¬ 
istics  (nomenclature,  description,  last  known  distributor,  manufacturer,  and  esti¬ 
mated  cost).  Item  managers  at  the  ICPs  need  to  obtain  both  components  of  the 
requests  and  enter  the  paper  documentation  into  an  automated  information  system. 
This  additional  action  results  in  added  costs  and  delays  (long  delays  if  the  paper 
submission  is  lost).  On  the  other  hand,  EDI  requisitions  transmit  all  requisition 
data  in  one  transaction  electronically. 

A  recent  survey  of  more  than  1 ,000  commercial  EDI  companies  identified  an  av¬ 
erage  savings  of  $2.20  per  transaction  converted  from  paper  to  EC.^  Applying  the 
transaction  savings  to  the  1.6  million  exception  requisitions  processed  by  the 
military  services  annually  yields  $3.5  million  in  savings.^ 

Discrepancy  Reporting 

Discrepancy  reports  are  issued  when  materiel  ordered  from  a  commercial  supplier 
or  a  DoD  depot  is  received  in  an  incorrect  manner.  DoD  uses  the  following  three 
major  types  of  discrepancy  reports: 

♦  Supply  discrepancy  reports  (SDRs,  formerly  reports  of  discrepancy 

[RODs]).  These  reports  are  typically  reports  of  shipping  errors  when  an  in¬ 
correct  quantity  is  received,  the  wrong  item  is  sent,  or  similar  problems 
occur.  These  discrepancies  are  numerous,  but  are  usually  easily  resolved. 


^  Daniel  M.  Ferguson,  “The  Real  Facts  of  EDI  in  1997,”  Journal  of  Electronic  Commerce, 
Volume  11,  Number  1,  p.  18. 

^  The  Navy  estimates  that  it  generates  540,000  exception  requisitions  a  year.  We  use  this 
amount  as  an  estimate  also  for  the  Army  and  Air  Force. 
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♦  Transportation  discrepancy  reports  (TDRs).  These  reports  are  used  when 
a  commercial  transporter  damages  or  loses  materiel,  or  delivers  an  item 
very  late.  TDRs  are  often  time-consuming  to  resolve  and  require  additional 
coordination  by  both  DoD  and  commercial  entities.  TDRs  are  especially 
complex  when  they  involve  legal  action  against  a  carrier  for  damages. 

♦  Product  quality  deficiency  reports  (PQDRs).  These  reports  are  prepared 
when  an  item  received  is  defective  because  a  manufacturing,  specification, 
or  other  quality  problem  has  occurred.  PQDRs  can  be  very  serious  as  they 
can  reflect  a  defective  item  that  has  been  distributed  throughout  the  DoD 
inventory  and  might  cause  an  end-item  failure. 

Each  type  of  discrepancies  is  processed  using  different  paper  forms.'^  The  costs  for 
identifying,  investigating,  and  resolving  the  discrepancies  are  high,  and  significant 
factors  are  mail  and  paper  handling  costs.  In  a  1994  report  for  the  JLSC,  LMI  es¬ 
timated  the  savings  for  using  EDI  discrepancy  reporting  to  be  $40  million  over 
6  years.^ 

Programming  Systems  with  Single  Exchange  Format 

The  DLSS  represent  the  standard  format  for  intra-service/agency  exchanges,  and 
the  military  services  and  defense  agencies  use  a  myriad  of  formats  for  internal  ex¬ 
changes.  In  addition,  data  are  exchanged  with  industry  in  other  formats  (EDI  or 
others).  Managing  the  diverse  formats  increases  DoD’s  ADP  training,  program¬ 
ming,  documentation,  and  maintenance  costs.  Additional  expenses  are  incurred  in 
creating  new  programs,  databases,  and  transactions  to  overcome  DLSS  limitations 
in  providing  serial  numbers,  unique  service  data,  and  other  data  that  can  be  carried 
in  standard  EDI  transactions.  Maintaining  unnecessary  DLSS  metadata  also  in¬ 
creases  operating  costs.  Related  actions  include  maintaining  routing  identifier 
codes,  media  and  status  codes,  multiple  date  formats,  fund  code  to  accounting  line 
relationships,  and  abbreviated  quantities. 

These  inefficiencies  are  only  a  few  that  exist  because  of  DLSS  limitations,  but  are 
so  diverse  and  obscure  as  to  preclude  a  comprehensive  analysis  in  a  limited  time. 
To  provide  an  initial  estimate,  we  use  the  previous  example  of  $2.20  savings  per 
transaction  of  EDI  in  replacing  paper  documentation.  We  assume  that  at  least  1 
percent  ($0,022)  of  the  savings  can  be  obtained  if  DoD  logistics  programming  or¬ 
ganizations  use  a  single  exchange  format,  consolidate  the  number  of  transactions 
and  codes,  and  eliminate  extra  system  development  efforts  caused  by  DLSS  limi¬ 
tations.  Extending  the  $0,022  by  the  two  billion  transactions  a  year  that  DAASC 


“  Several  military  services  have  independently  automated  a  portion  of  discrepancy  reporting 
actions,  and  JLSC  developed  an  initial  discrepancy  reporting  system.  However,  no  comprehensive 
system  has  ever  been  employed. 

*  Logistics  Management  Institute,  Deficiency  Reporting  System  Functional  Economic  Analysis 
Mini-Business  Case,  AR328LN1,  Donald  F.  Egan  and  Richard  F.  Shepherd,  April  1994. 
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processes  (these  transactions  exclude  service  and  agency  transactions  not  routed 
through  DAASC)  yields  $44  million  in  savings  a  year. 

This  approach  is  reasonable  in  light  of  related  cost  estimates.  In  establishing  the 
Distribution  Standard  System,  DLA  incurred  costs  of  $10  million  to  establish 
links  to  unique  service  systems  and  data.  In  addition,  the  Army  is  estimating  costs 
of  $40  million  to  link  its  legacy  systems  and  data  to  the  Standard  Procurement 
System. 

Linking  Commercial  Systems  to  DoD  Systems 

Such  costs  are  not  limited  to  DoD  systems.  Implementing  standard  X12-based  lo¬ 
gistics  transactions  will  facilitate  reengineering  the  contractor  depot  repair  process 
to  achieve  the  projected  savings  and  overcome  the  difficulties  experienced  in  de¬ 
veloping  and  deploying  standard  systems,  such  as  Commercial  Asset  Visibility  11 
(CAV II).  CAV II  is  a  Navy-developed  system  to  improve  the  visibility  and  con¬ 
trol  of  reparable  materiel  at  commercial  repair  facilities.  The  Navy  uses  CAV  II  at 
180  contractor  sites.  The  Marine  Corps  will  begin  deployment  to  its  contractors  in 
late  1998.  Originally  chosen  by  DoD  to  be  a  standard  system,  CAV  II  is  no  longer 
being  implemented  by  all  military  services,  and  they  are  free  to  pursue  different 
systems.  CAV  11  and  similar  standeu'd  system  solutions  have  several  disadvan¬ 
tages.  In  addition  to  the  ones  previously  discussed,  the  disadvantages  include  the 
following: 

♦  Difficulty  in  developing  and  deploying  a  standard  system 

♦  Costly  and  difficult  deployment  and  management  of  government-furnished 
hardware  and  software 

♦  Redundancy  of  data  in  a  contractor’s  internal  management  system  and 
government-provided  systems 

♦  Duplicative  data  entry  and  manipulation. 

Unquantified  Benefits 

This  section  discusses  benefits  derived  from  reengineering  logistics  processes  that 
cannot  be  quantified  without  determining  the  scope  of  the  reengineering  effort.  In 
this  section  we  cite  only  two  of  the  many  potential  examples. 

Prime  Vendor  Programs 

DLA  has  been  very  successful  in  establishing  prime  vendor  programs  in  subsis¬ 
tence,  medical  supplies,  and  clothing  and  textiles.  In  prime  vendor  programs, 

DLA  contracts  with  commercial  firms  to  support  all  DoD  activities  in  a  geo¬ 
graphical  region  for  a  commodity  (e.g.,  subsistence).  A  DoD  activity  orders 
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directly  from  a  vendor  (with  the  DLA ICP  receiving  a  copy  of  the  electronic 
transaction),  and  the  vendor  delivers  items  directly  to  the  activity,  usually  in 
36  hours  or  less.  This  program  provides  significant  benefits  in  reducing  inventory 
management,  warehousing,  and  distribution  costs.  It  also  dramatically  reduces  cy¬ 
cle  time.  For  subsistence  items,  the  program  also  improves  morale  as  brand  names 
used  by  the  prime  vendors  have  better  acceptance  than  unknown  or  generic  brands 
provided  by  the  depots. 

The  savings  in  these  programs  can  be  further  extended  as  prime  vendor  invoices 
are  transmitted  to  DFAS  electronically  and  even  more  if  concepts,  such  as  evalu¬ 
ated  receipts  settlement,  are  used  to  eliminate  invoices.  Prime  vendor  programs 
can  be  extended  to  additional  commodities,  but  the  managing  ICPs  need  to  select 
the  candidate  items  and  schedules.  EDI  is  a  key  part  of  the  prime  vendor  program 
because  DoD  orders  are  sent  to  commercial  suppliers,  and  suppliers  provide 
DFAS  with  EDI  invoices  as  EDI  exchanges. 

Contractor  Depot  Repair 

One  major  area  identified  for  DoD  outsourcing  opportunities  is  extending  weap¬ 
ons  systems  maintenance  beyond  the  current  43  percent  level  performed  by  or¬ 
ganic  repair  activities.  Savings  in  the  area  of  commercial  depot  repair  of 
secondary  items  could  potentially  exceed  $2.2  billion,  including  a  one-time 
$1  billion  reduction  in  inventory.^  For  contractors  to  perform  as  maintenance  de¬ 
pots,  they  need  to  be  full  members  of  DoD  supply-chain  operations.  Several  stand¬ 
alone  systems  have  been  developed  by  the  military  services  to  accommodate  this 
performance.  However,  in  many  cases,  this  action  has  required  extensive  pro¬ 
gramming  to  include  development  of  government-provided  software  and  hard¬ 
ware.  Further,  the  existing  DLSS  transaction  limitations  preclude  transmitting  all 
required  and  desired  data  electronically.  The  stand-alone  systems  use  unique 
transaction  records  that  are  not  easily  imported  into  or  exported  from  the  leg¬ 
acy  systems  and  do  not  meet  all  reporting  requirements.  As  a  result,  full 
implementation  of  outsourcing  initiatives  to  achieve  these  savings  is  difficult. 

Intangible  Benefits 

Although  the  intangible  benefits  are  many,  the  primary  ones  identified  in 
Chapter  2  include  the  following: 

♦  Being  compliant  with  FIPS  161-2  and  federal  EC  and  EDI  initiatives 
for  exchanges  with  industry,  and  extending  the  formats  to  include 
intra-service/agency  exchanges. 


®  Logistics  Management  Institute,  Contractor  Depot  Repair  of  Secondary  Items:  An  Applica¬ 
tion  for  Business  Process  Reengineering,  Report  LG609R1,  Larry  S.  Klapper  and  Kelvin  K. 
Kiebler,  September  1997. 
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♦  Establishing  data  independence  between  legacy  systems  and  the  exchange 
format.  This  independence  encourages  system  modernization  (either 
through  enhancement  of  existing  systems  or  replacement  by  COTS)  and 
evolution  as  new  hardware  and  software  technologies  become  available.  It 
also  enables  DoD  to  implement  EDI’s  eventual  replacement  more  easily 
than  attempting  to  implement  it  directly  from  the  DLSS. 

♦  Simplifying  electronic  exchanges  with  industry  for  many  initiatives. 

Summary 

Replacing  the  DLSS  is  an  infrastructure  modernization  effort  needed  for  DoD  to 
meet  functional  data  requirements,  support  reengineering  initiatives,  and  engage 
in  new  technologies.  It  will  also  reduce  ADP  costs  and  facilitate  opportunities  to 
obtain  greater  savings  through  reengineering  initiatives.  Although  we  readily  ad¬ 
mit  that  both  the  cost  and  benefits  estimated  in  this  chapter  are  approximate,  we 
believe  they  clearly  indicate  tangible  and  intangible  benefits  to  justify  DLMS  im¬ 
plementation. 
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Chapter  6 

Logistics  Data  Exchanges  in  Defense  Logistics 
Management  System  Environment 


This  chapter  describes  the  anticipated  EDI  operating  and  technical  environment 
and  the  exchange  of  DLMS  EDI  transaction  sets  in  that  environment. 

Functions  and  Formats 

The  DLMS  will  support  the  following  critical  logistics  functions: 

♦  Requisitioning 

♦  Inventory  management 

♦  Billing 

♦  Transportation 

♦  Contract  administration 

♦  Discrepancy  reporting  and  tracking. 

These  functions  will  continue  to  be  supported  by  the  legacy  systems.  The  DLMS 
will  also  support  the  diverse  retail  inventory  and  requisition  systems  of  the  DoD 
components.  However,  where  DLSS  formats  were  intertwined  into  the  program 
code  of  these  systems  and  inhibited  modernization  efforts,  the  DLMS  formats  will 
be  independent.  This  design  frees  the  DLMS  (and  the  systems)  to  evolve  with  new 
DoD  logistics  initiatives  and  new  technology.  In  the  interim,  DLMS  will  support 
service  and  agency  legacy  systems  in  their  need  for  redundant  coding  until  those 
systems  are  modernized. 

Logistics  Organizations 

The  DLMS  will  continue  to  support  the  following  logisties  organizations  that  use 
the  DLSS: 

♦  Retail  sites  of  all  military  services  and  DoD  agencies,  including  fixed 
bases;  units  stationed  at  these  bases,  in-transit,  or  in  an  operational  de¬ 
ployment;  Navy  ships;  and,  on  an  increasing  basis,  joint  commands  that 
oversee  the  use  of  materiel  and  support  assets  during  operations 
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♦  Depots — ^both  distribution  and  maintenance 

♦  ICPs  and  materiel  managers 

♦  Retail  and  wholesale  levels  of  civil  agencies,  including 
^  GSA, 

►  Federal  Aviation  Administration,  and 

►  U.S.  Coast  Guard 

♦  DFAS 

♦  Commercial  contractors  participating  in  DoD  logistics  operations 

♦  Activities  supporting  specialized  functions,  such  as  foreign  military  sales 
and  disposal. 

Several  organizations,  including  DLMSO,  DISA,  and  DAASC,  will  help  operate 
the  DLMS.  Their  functions  are  described  in  this  chapter  and  Chapter  3. 

Technology  and  Business  Influences 

The  DLMS  is  the  implementation  of  the  commercial  ASC  XI 2  standards  for  EDI. 
The  DLMS  EDI  is  compliant  and  consistent  with  the  following  initiatives  and 
standeu'ds: 

♦  FIPS  161-2  for  using  EDI  to  exchange  data  among  federal  agencies  and 
with  external  trading  partners 

♦  Adoption  of  industry  standards 

♦  Use  of  COTS  software 

♦  The  following  related  DoD  technical  initiatives: 

►  GCSS 

►  JTA 

DH  and  COE 

►  Defense  Interoperable  Information  Environment. 

The  DLMS  define  a  data  standard  and  transaction  format  that  are  used  between 
systems  and  are  independent  of  any  application  system.  The  DLMS  can  operate 
with  any  legacy  system  of  the  DoD  components,  civil  agencies,  and  contractors. 
Replacing  the  DLSS  with  variable-length  transactions  that  are  independent  of 
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applications  will  promote  and  assist  in  the  transition  to  next-generation  sys¬ 
tems  and  a  shared  data  environment  that  will  comply  with  the  DII  and  COE. 

Legacy  Systems  and  EDI 

The  existing  legacy  systems  that  generate  requisitions,  inventory  adjustments,  and 
more  than  400  other  DLSS  transactions  will  continue  to  operate  with  the  DLMS.^ 
A  one-time  revision  consisting  of  the  following  three  operations  will  be  needed  to 
convert  these  systems  to  EDI: 

♦  Revise  input  and  output  routines.  The  DLSS  input  and  ouq)ut  routines  of 
all  DLSS-related  legacy  systems  will  need  to  be  revised  from  the  DLSS  to 
DLMS  format.  The  changes  will  be  numerous,  but  they  will  not  change  the 
basic  functions  of  the  programs  except  as  noted  in  the  following  two  op¬ 
erations. 

♦  Support  additional  functionality.  The  DLMS  accommodate  enhanced  data, 
such  as  unique  item-tracking  data  and  additional  transportation  identifica¬ 
tion  numbers  to  support  TAV.  If  the  supporting  application  system  already 
contains  the  data  elements,  few  changes  will  be  needed  except  to  add  the 
data  elements  to  the  input  and  output  routines.  However,  if  the  application 
system  and  process  do  not  contain  the  data  or  procedures  to  support  the 
initiative,  more  significant  changes  are  required. 

♦  Eliminate  service/agency  unique  transactions.  Because  the  DLSS  transac¬ 
tion  formats  are  inflexible  and  have  size  restrictions,  the  DoD  components 
have  developed  a  wide  variety  of  transactions  to  contain  intracomponent 
logistics  data.  The  unique  transaction  types  probably  exceed  the  more  than 
400  DLSS  transaction  types,  and  their  number  of  annual  transmissions 
also  probably  exceeds  the  approximately  one  billion  DLSS  exchanges. 
These  unique  formats  vary  significantly  from  80-column  formats  (similar 
to  the  DLSS  format)  to  extremely  long  fixed-length  and  variable-length  re¬ 
cords.  Using  DLMS  and  EDI  can  eliminate  these  redundant  transactions. 
The  DoD  components,  in  cooperation  with  DLMSO,  need  to  take  one  of 
following  three  actions  for  each  internal  transaction: 

>-  For  unique  transactions  that  are  shadows  of  DLSS  transactions  but 
contain  data  that  the  DLSS  cannot  carry,  incorporate  the  significant 


*  At  the  ICPs,  the  legacy  systems  include  Commodity  Command  Standard  System,  Army; 
Stock  Control  System  (and  other  modules),  Air  Force;  Unified  ICP  System,  Navy  and  Marine 
Corps;  and  Standard  Automated  Materiel  Management  System,  DLA.  DLA  also  operates  the 
Distribution  Standard  System  at  its  distribution  depots.  In  addition,  the  military  services  operate 
many  retail  systems. 
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data  elements  into  the  associated  DLMS  transaction  set  and  eliminate 
the  unique  transactions.^ 

>-  For  unique  transactions  of  a  DoD  component  that  are  distinct  from  the 
DLSS  but  have  the  same  functionality  as  transactions  used  by  at  least 
one  other  DoD  component,  incorporate  the  transactions  as  new  DLMS 
transactions  and  eliminate  the  unique  transactions. 

►  For  the  remaining  transactions  (that  are  truly  unique  to  a  service  or 
agency),  leave  them  under  the  jurisdiction  of  the  service  or  agency  but 
convert  them  to  an  X12  EDI  format. 


EDI  Technology 

After  the  input  and  output  routines  of  the  legacy  systems  are  converted,  the  sys¬ 
tems  will  operate  with  EDI  without  any  loss  of  functionality.  When  a  transaction, 
such  as  a  requisition,  is  ready  to  be  sent,  the  application  system  gathers,  formats, 
and  sends  the  related  data.  After  the  data  leaves  the  legacy  application  system,  the 
DLSS  and  EDI  environments  will  be  very  different.  For  DLSS  processing,  the 
output  file  is  in  the  format  used  to  transmit  it.  For  EDI  processing,  the  data  are 
transformed  as  described  in  the  following  subsections. 

Implementation  Conventions 

Because  the  ASC  XI 2  standards  are  designed  to  accommodate  a  wide  variety  of 
users,  ASC  developed  the  concept  of  ICs.  ICs  define  how  a  community  (e.g., 
transportation  industry,  aircraft  industry,  DLMS  users)  uses  the  standards. 
DLMS  EDI  ICs  are  documents  that  are  the  key  to  military  services’  and  de¬ 
fense  agencies’  ability  to  write  interface  programs  and  subsequent  DLMS  transac¬ 
tions.  ICs  define  the  following  items  for  programmers  of  the  generating  system: 

♦  Data  elements  to  be  included,  and  if  they  are  mandatory  or  optional 

♦  Format  of  data  elements  (e.g.,  all  dates  use  a  ccyymmdd  format)^ 

♦  Order  of  data  in  the  XI 2  transaction  sets 

♦  Activities,  by  type,  that  are  to  receive  the  transaction  set 

♦  Specific  rules  and  formats  for  the  contents  of  data  in  the  data  elements. 


^  The  DLMS  (unlike  the  DLSS)  has  an  unlimited  capacity  to  accommodate  unique  data  ele¬ 
ments. 

^  With  their  conversion  to  ASC  X12  version  4.0,  the  DLMS  transactions  will  be  year  2000 
(Y2K)-compliant.  However,  the  DLMS  capability  to  carry  eight-position  dates  does  not  make  the 
application  systems  Y2K-compliant.  The  ccyymmdd  format  provides  two  numbers  for  the  century, 
year,  month,  and  day. 
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System  programmers  use  the  ICs  to  write  the  application  interface  programs  and 
map  the  translation  software. 

Interface  and  Translation  Software 

The  output  of  an  application  system  is  a  file  containing  the  DLMS  data  elements 
and  format-related  information.  The  output  routines  that  extract  the  data  from  the 
application  system  and  create  the  format  are  called  interface  programs.  The 
resulting  file  is  often  called  a  user  defined  file  (UDF),  ox  flat  file.  In  addition  to 
creating  the  UDF,  the  interface  software  edits  the  output  data  elements  to  ensure 
they  are  correct  and  DLMS-compliant  and  can  also  make  copies  of  the  transaction 
set  when  it  is  to  be  sent  to  additional  addressees.'* 

As  Figure  6-1  depicts,  the  UDF  is  provided  to  a  COTS  EDI  translator  program. 
The  EDI  translator  converts  data  between  X12  and  UDF  formats.^  It  can  also  per¬ 
form  a  number  of  other  functions,  including  maintaining  telecommunications 
data,  archiving  messages,  and  processing  errors.  The  brand  of  EDI  translation 
software  may  determine  the  structure  of  the  UDF.  The  output  of  the  translation 
software  is  an  XI 2  EDI  format  ready  for  transmission  to  a  recipient.  The  interface 
software  is  unique  to  the  ADP  system  or  activity  and  is  written  in  the  standard 
programming  language  used  by  the  CDA  for  the  application  and  database  man¬ 
agement  system.  Translation  software  should  always  be  purchased  from  a 
commercial  source.^ 

The  example  in  Figure  6-1  describes  a  typical  EDI  site  environment  and  the  model 
used  most  frequently  in  the  commercial  world.  The  interface  software  operates  on 
the  same  hardware  platform  as  the  application  system,  and  the  translation  software 
operates  on  the  same  or  a  smaller  hardware  platform  in  the  same  facility. 


''  After  more  than  35  years  of  DLSS  operations,  DAAS  still  rejects  approximately  1  percent  of 
incoming  transactions  for  errors. 

^  The  cost  associated  with  acquiring  COTS  translation  software  and  completing  the  necessary 
setup  and  testing  is  sometime  cited  as  a  reason  not  to  implement  EDI.  However,  the  translation 
step  allows  for  a  standard  interorganization  format  to  be  used  while  permitting  the  underlying  ap¬ 
plications  (legacy  systems)  to  be  data  format  independent  and  free  to  evolve.  The  intertwine  of  the 
DLSS  formats  with  the  application  systems  has  been  a  major  factor  inhibiting  previous  system 
modernization  efforts.  One  alternative  to  translators  and  translation  that  is  sometimes  proposed  is 
to  exchange  the  UDFs  or  translate  only  at  DAASC.  However,  if  a  single  UDF  format  is  used,  this 
process  is  simply  a  return  to  the  DLSS  by  another  name.  Alternatively,  a  chaotic  mix  would  occm 
because,  for  example,  the  UDF  of  a  direct  vendor  delivery  contractor  would  not  be  the  same  as  that 
of  the  service’s  or  agency’s  requisitioner. 

*  Several  commercial  database  management  system  manufacturers  also  provide  integrated  EDI 
translation  software  that  bypasses  the  UDF  stage  and  translates  the  data  directly  into  an  X12  for¬ 
mat 
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Figure  6-1.  Processing  Data  from  Application  System 
to  Transmission  in  ASC  XI 2  Format 


However,  as  shown  in  Figure  6-2,  the  services  and  agencies  have  the  following 
options  for  locating  their  translation  software  and  hardware: 

♦  The  EDI  translation  capability  can  be  shared  among  several  locations  and 
functions.  For  example,  the  translator  that  supports  the  DLMS  can  also  be 
used  by  procurement  or  other  functions. 

♦  A  single  translation  hardware  and  software  suite  that  is  appropriately 
sized  can  support  all  EDI  operations  of  a  typical  large  continental 
United  States  (CONUS)  military  installation. 

♦  For  low-volume  customers,  the  EDI  translation  can  also  be  offered  on  a 
regional  basis.  In  addition,  very  low-volume  users  might  benefit  by  simply 
transmitting  their  UDFs  directly  to  DAASC,  which  provides  translation 
capabilities. 

Tbe  selection  and  placement  of  tbe  most  cost-effective  translation  software  and 
hardware  and  telecommunications  hardware  and  software  will  vary  by  each  DoD 
component  and  even  by  each  site.  A  detailed  analysis  of  the  existing  environment 
and  planned  EDI  exchanges  with  industry  and  DLMS  EDI  operations  will  be 
needed  to  complete  a  selection  and  placement  decision.  The  Navy,  with  OSD 
assistance,  has  acquired  EDI  translation  software  and  is  placing  it  on  all  afloat 
units. 


Telecommunications 

The  DLSS  initially  used  a  single  dedicated  telecommunications  path — 
AUTODIN.  AUTODIN  was  established  in  the  mid-1960s  to  support  DLSS 
communications.  However,  it  is  now  based  on  outdated  technology,  and  DISA 
officially  terminated  its  support  in  November  1997.  DISA  is  still  maintaining 


6-6 


Logistics  Data  Exchanges  in  Defense  Logistics  Management  System  Environment 


AUTODIN  on  an  interim  basis  as  some  military  services  and  defense  agencies 
convert  to  other  networks. 

Figure  6-2.  Alternative  EDI  Translation  Scenarios 


The  DLMS  will  rely  on  a  broad  array  of  telecommunications  networks.  DISA’s 
Nonsecure  Internet  Protocol  Router  Network  (NIPRNET),  a  combination  of 
DISA-managed  communication  lines  and  the  Internet,  will  be  the  primary  path  for 
DLMS  communications  in  CONUS.  Units,  including  Navy  ships  at  sea,  outside 
CONUS  will  use  a  variety  of  communications  paths  to  connect  to  DISA  com¬ 
munications  channels.  In  some  cases,  these  paths  will  consist  of  assets  managed 
by  a  DoD  component,  and,  in  other  cases,  they  will  be  managed  by  DISA.  In  lim¬ 
ited  cases,  the  paths  may  even  be  commercial  assets.  The  paths  will  include  satel¬ 
lite  communications,  including  the  Navy’s  Copernicus  system  and  the  Internet. 

Civil  agency  and  commercial  participants  in  the  DLMS  will  also  require  commu¬ 
nications  capabilities.  Civil  agency  participants  will  generally  connect  to  a  DISA 
megacenter  and  from  the  megacenter  to  DAASC  through  NIPRNET.  Many  com¬ 
mercial  participants  will  be  active  in  other  EDI  exchanges  (e.g.,  procurement) 
with  government  agencies,  although  some  participants  will  use  only  the  DLMS. 
The  commercial  DLMS  trading  partners  may  work  through  their  VANs  that  con¬ 
nect  to  DISA  and  from  DISA  to  DAASC  via  NIPRNET.  Alternatively,  the  trading 
partners  may  connect  directly  to  DAASC  through  commercial  lines  that  DAASC 
accesses  or  through  the  Internet. 
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Any  of  these  networks  can  be  accessed  directly  by  any  telecommunications- 
capable  application  system  of  the  DoD  components.  Computers  can  be  linked  to 
the  long-line  network  through  local  or  wide  area  networks  as  opposed  to 
AUTODIN,  which  requires  connections  to  a  limited  number  of  AUTODIN 
node  points.  The  DLMS  communications  approach  is  also  very  robust.  In  an 
emergency,  almost  any  telecommunication  link  can  be  used,  as  opposed  to  the 
significant  dependence  on  AUTODIN  by  the  DLSS. 

Defense  Automatic  Addressing  System  Center  Processing 

DAASC  will  continue  to  serve  as  a  central  focus  for  most,  if  not  all,  logistics 
transactions  among  the  DoD  components  in  the  DLMS  environment.  The  op¬ 
erations  DAASC  performs  for  a  transaction  varies  greatly  by  the  message  type, 
sender,  and  intended  recipient.  Historically,  DAASC  has  performed  the  following 
functions: 

♦  Archive  all  inbound  and  outbound  transactions 

♦  Route  messages  to  correct  recipients  and  locations,  especially  for  units  that 
are  deploying  or  conducting  an  operation 

♦  Group  transactions  from  different  sources’ 

♦  Open  messages  and  conduct  standard  or  recipient-specific  edits^ 

♦  Place  opened  messages,  especially  requisition-related  transactions,  in  LIPS 
or  route  them  to  other  DoD  databases,  such  as  the  Global  Transportation 
Network 

♦  Perform  specialized  functions,  such  as  coordinating  the  Defense  Program 
for  Redistribution  of  Assets 

♦  Forward  messages  outside  the  DoD  telecommunications  network  to  civil 
agencies  and  commercial  trading  partners 

♦  Use  LIPS  to  monitor  supply  system  efficiency.^ 


’  In  special  cases,  DAASC  can  hold  traffic  and  convert  media  types. 

*  Based  on  customer-approved  procedures  for  data  that  fail  the  edits,  DAASC  can  either  return 
the  transaction  to  the  sender  or  modify  and  forward  the  data  to  the  recipient. 

*  In  the  DLSS,  the  Military  Standard  Supply  and  Transportation  Evaluation  Procedures 
(MILSTEP)  provided  measures  of  supply  system  performance,  especially  indicators  of  fill  rates  for 
requisitions  and  average  requisition  response  times.  MILSTEP  consisted  of  structured  and  volumi¬ 
nously  printed  monthly  reports.  The  reports  were  produced  by  the  cumbersome  process  of  depots, 
ICPs,  and  other  participants  sending  tapes  to  DAASC  where  the  reports  were  compiled.  The  Lo¬ 
gistics  Metric  Analysis  Reporting  System  replaced  MILSTEP  and  provides  on-demand  standard 
and  tailored  queries  and  reports. 
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In  addition,  DAASC  will  provide,  as  requested,  translations  between  UDF  formats 
of  the  DoD  components  and  the  ASC  X12  standards  and,  during  the  transition 
period,  conversion  between  DLMS  and  DLSS  formats.  After  DAASC  has  per¬ 
formed  a  specified  action  on  a  transaction,  it  forwards  the  transaction  to  the  re¬ 
cipient. 

Receiver’s  Processing 

The  receiver’s  process  is  compatible  with  the  sender’s  process.  An  activity  re¬ 
ceiving  DLMS  transactions  from  DAASC  should  generally  receive  an  XI 2 
format  into  its  translation  suite.  The  translation  software  creates  a  UDF  or  other 
site-specific  format.  The  software  validates  the  incoming  file  for  compliance  with 
the  X12  syntax.  The  translator  can  accept  the  data,  accept  the  file  with  errors,  or 
reject  the  transaction.  If  the  file  is  rejected,  it  is  returned  to  the  originator  by 
DAASC.  An  application  interface  program  processes  and  enters  the  data  in  the 
receiving  application  software’s  database.  Depending  on  the  number  and  type  of 
application  systems  that  the  receiving  activity  operates,  the  interface  program 
software  can  be  very  simple  or  sophisticated.  In  addition  to  converting  the  UDF 
file  into  the  application’s  internal  format,  the  program  can  also  perform  the 
following  functions: 

♦  Analyze  the  incoming  transactions  and  route  them  appropriately  (when  the 
activity  operates  several  application  systems) 

♦  Determine  recipients  for  outbound  transactions  and  make  multiple  copies 
to  send  to  the  translator 

♦  Maintain  tickler  files  for  outbound  transactions  that  have  not  received  an 
expected  responding  transaction 

♦  Perform  edit  checks  and  validations. 

The  EDI  approach  is  both  open  and  flexible.  Although  senders  and  recipients  use 
the  DLMS  transaction  formats  and  procedures,  their  EDI  architecture  may  be  very 
different.  Senders  and  receivers  may,  of  course,  have  a  different  application  sys¬ 
tem.  They  may  use  different  interface  programs,  UDFs,  and  translation  software 
packages.  Senders  and  receivers  may  also  apply  different  architectures  to  the  plat¬ 
form,  location,  and,  to  some  extent,  the  functions  of  the  interface  programs  and 
the  translation  software. 
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Summary 


DLMS  EDI  will  support  all  the  critical  logistics  users  and  functions  that  the  DLSS 
have  supported  for  35  years.  EDI  will  also  support  new  functionality.  Further,  by 
separating  the  legacy  systems  from  the  transmission  format,  the  DLMS  allows 
these  systems  greater  freedom  to  evolve  with  new  hardware  and  software  tech¬ 
nologies.  Appendix  B  provides  more  information  on  the  DLMS  operational 
environment. 
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Chapter  7 

Conclusion 


The  DLSS  were  established  in  the  1960s  to  eliminate  the  independent  efforts  of 
the  military  services  and  defense  agencies  to  exchange  materiel  management 
data.  Those  efforts,  if  continued,  would  have  been  more  costly  and  reduced 
interoperability.  For  many  years  the  DLSS  have  effectively  served  that  purpose. 

However,  because  of  the  limitations  of  the  fixed-length  formats,  the  services  and 
agencies  have  needed  to  either  bypass  or  alter  the  formats.  This  action  is  causing 
increased  costs  and  inconsistent  methodologies  that  the  DLSS  were  intended  to 
prevent.  The  DLSS  formats  and  transactions  do  not  support  today’s  data  require¬ 
ments.  In  addition,  they  do  not  reflect  current  and  future  means  for  providing  lo¬ 
gistics  support  through  the  increased  use  of  commercial  assets  and  related 
initiatives. 

DoD  needs  a  better  means  to  exchange  critical  logistics  data  for  the  new  initia¬ 
tives,  new  data,  and  new  technology  to  support  its  operational  forces  as  defined  by 
Joint  Vision  2010.  EDI  is  a  proven  and  effective  means  of  exchanging  business 
data  and  the  procedures  for  using  it  to  replace  the  DLSS  have  already  been 
developed. 

Because  of  the  breadth  and  the  depth  of  the  DLSS  formats  and  procedures  in  the 
logistics  legacy  systems,  careful  and  coordinated  planning  will  be  needed  to  man¬ 
age  the  implementation  effort.  The  DLSS  transmit  data  across  agency,  function, 
and  system  boundaries.  As  a  result,  implementation  efforts  need  the  active  and 
closely  coordinated  participation  of  all  involved  parties.  Logistics  EDI  cannot  be 
unilaterally  implemented.  For  these  reasons,  this  report  establishes  the  need  for 
high-level  DoD  management  direction  and  support  to  coordinate  implementation 
efforts. 
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Appendix  A 

Defense  Logistics  Management  System 


This  appendix  provides  additional  information  on  the  development  of  the  DLMS 
initiative  presented  briefly  in  Chapter  1. 

Origins  of  DLSS 

In  the  late  1950s  and  early  1960s,  DoD  replaced  the  practice  of  each  military 
service  independently  procuring  materiel  with  the  single  item  manager  concept. 
Under  this  concept,  each  item  in  the  DoD  inventory  is  assigned  to  DLA,  a 
military  service,  GSA,  or  another  agency  to  manage.^  Single  item  management 
requires  considerable  communications  among  the  managing  activities,  commer¬ 
cial  sources  of  materiel,  distribution  and  maintenance  depots,  and  users.  To  fa¬ 
cilitate  communications,  DoD  established  MILSTRIP  in  July  1962.  It  defined 
DoD  procedures  and  formats  for  requisitioning  supplies. 

Recognizing  the  success  of  MILSTRIP,  DoD  developed  several  related  proce¬ 
dures  during  the  next  15  years  in  the  functional  areas  listed  in  Table  2-1  of 
Chapter  2.  Collectively,  those  procedures  are  known  as  the  DLSS.  (Figure  2-1  in 
Chapter  2  illustrates  the  DLSS  data  flows.) 

Making  the  DLSS  successful  required  more  than  standardized  procedures.  After 
establishing  MILSTRIP,  DoD  used  the  increasing  power  of  computers  and  tele¬ 
communications  to  convert  paper  forms  into  electronic  information.  AUTODIN 
and  DAAS  were  the  foundations  for  that  conversion,  as  follows: 

♦  AUTODIN  was  installed  to  support  worldwide  military  communications. 

♦  DAAS  was  established  to  perform  the  functions  of  receiving,  validating, 
and  routing  transactions  to  the  correct  addressee. 

The  combination  of  AUTODIN  and  DAAS  enabled  DoD  to  process  nearly 
5.5  million  transactions  each  day,  compared  to  only  35,000  daily  transactions  pos¬ 
sible  with  paper-based  procedures.  The  DLSS  have  been  the  central  compo¬ 
nent  of  logistics  data  exchanges  since  1965. 


'  Responsibilities  of  a  single  item  manager  include  procuring,  managing,  and  distributing  ma¬ 
teriel  to  users. 
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The  DLSS,  in  combination  with  DAAS  and  AUTODIN,  moved  DoD  to  the  lead¬ 
ing  edge  of  1960-era  technology.  However,  the  technology  embodied  in  the  DLSS 
and  many  supporting  ADP  systems  of  the  military  services  and  defense  agencies 
remains  about  as  it  was  in  the  1970s.  In  the  intervening  35  years,  the  capabilities 
provided  by  computer  and  telecommunications  technology  have  expanded  enor¬ 
mously,  as  have  DoD’s  logistics  capabilities.  That  revolutionary  growth  has 
spurred  increased  demands  for  logistics  data  that  the  fixed-length  DLSS  cannot 
readily  support. 

The  ability  of  the  DLSS  to  meet  these  requirements  has  been  further  reduced  as 
the  military  services  modernized  their  internal  logistics  processes  (usually  to  sat¬ 
isfy  similar  user  requirements).  These  system  modernization  efforts  have  pro¬ 
ceeded  at  different  rates  and  along  different  approaches  in  each  military  service. 
The  combined  effects  have  produced  disjointed  logistics  capabilities  and  the  re¬ 
surgence  of  nonstandard  procedures  and  transactions  by  the  DoD  components — 
the  amount  of  nonstandard  transactions  is  estimated  to  exceed  that  of  standard 
transactions. 

DLSS  Limitations 

Most  DLSS  problems  stem  simply  from  the  limitation  of  the  fixed-length  format. 
The  following  examples  illustrate  the  complexity  and  limitations  that  have 
resulted: 

♦  The  standard  DoD  activity  and  unit  identification  is  a  six-position  DoD 
activity  address  code.  However,  to  reduce  space  the  DLSS  use  a  three- 
position  routing  identifier  code  to  identify  ICPs,  depots,  and  other  logistics 
organizations. 

♦  Dates  appear  in  a  wide  variety  of  formats;  most  are  four-position  (yddd) 
Julian  dates.  However,  three-position  Julian  dates  and  other  formats  are 
alternatives. 

♦  Numerous  other  metacodes  (including  Signal  Code  and  Media  and  Status 
Code)  have  little  functional  value. 

♦  Quantities  are  limited  to  five  positions.  Special  rules  deal  with  quantities 
greater  than  those  sizes. 


^  The  yddd  format  provides  one  number  for  the  year  and  three  numbers  for  the  day. 
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♦  The  space  for  unique  data  of  the  DoD  components  is  limited.  As  a  result, 
the  space  used  for  many  purposes  is  not  documented. 

♦  Several  occurrences  of  the  data  cannot  be  accommodated.  For  example, 
the  ASl  shipment  status  of  a  group  of  small  arms  identifies  the  quantity  of 
weapons  shipped,  the  shipment  identification,  shipment  date,  and  other 
information,  but  cannot  transmit  a  weapon’s  serial  number. 

DLMS  Development 

The  DoD  responded  to  meet  user  requirements  and  take  advantage  of  new  tech¬ 
nologies  by  initiating  the  Modernization  of  the  Defense  Logistics  Standard  Sys¬ 
tems  (MODELS)  Program.  The  DoD  memorandum  that  initiated  MODELS  states, 
“It  is  not  merely  an  update  of  assorted  procedures  but  a  fundamental  redesign  of 
the  way  DLSS  functions  are  performed.”  To  reflect  the  fundamental  change 
planned  for  the  system,  a  new  name — the  Defense  Logistics  Management 
System — was  assigned. 

The  Logistics  Management  Institute  was  tasked  to  review  the  DLSS  and  the  un¬ 
derlying  logistics  functions  and  provide  recommendations  for  their  modernization. 
The  fundamental  recommendation  was  to  replace  the  fixed-length  DoD  proprie¬ 
tary  transaction  format  with  a  variable-length  national  and  commercial  standard 
called  EDI.  Ironically,  the  EDI  standards  recommended  to  replace  the  DLSS  were 
inspired  by  former  DoD  employees  taking  lessons  from  the  DLSS  and  other  mili¬ 
tary  techniques  to  establish  EDI  in  the  commercial  world.  EDI  as  known  today 
was  established  in  the  late  1960s  by  the  Transportation  Data  Coordinating  Com¬ 
mittee.  The  committee  was  established  by  a  joint  group  of  railroad  companies  to 
determine  automated  means  of  tracking  rail  cars.  The  resulting  electronic  stan¬ 
dards  concepts  soon  spread  to  other  transportation  modes  and  other  industries. 

The  concept  was  successful,  but  individual  implementation  has  veuied  in  format. 
Several  companies  implemented  proprietary  standards  to  obtain  a  competitive  ad¬ 
vantage.  As  a  result,  many  companies  requested  that  the  American  National  Stan¬ 
dards  Institute  establish  national  standards  for  EDI.  The  first  release  of  these 
standards  occurred  in  1977,  and  they  are  known  today  as  the  ASC  X12  EDI 
standards. 

During  the  next  20  years,  virtually  all  large  American  corporations  implemented 
some  form  of  an  EDI  program.  Typical  transactions  include  purchase  orders, 
shipment  notices,  manifests,  materiel  receipts,  and  invoices.  In  the  early  1990s, 
several  federal  agencies  began  using  ASC  XI 2  EDI  transactions  to  support  a  wide 
variety  of  operations.  FIPS  161-2,  in  May  1996,  established  ASC  X12  as  the  ap¬ 
proved  means  to  exchange  electronic  data  between  federal  agencies  and  be¬ 
tween  agencies  and  their  commercial  trading  partners. 


A-3 


Variable-Length  Formats 


After  accepting  the  recommendation  to  use  ASC  XI 2  EDI  formats,  DLMSO 
tasked  the  Logistics  Management  Institute  to  develop  standards  that  support  the 
DLSS  functionality.  This  task  began  a  3-year  effort  to  revise  and  add  additional 
X12  standards  to  meet  DoD  requirements.  More  than  425  DLSS  fixed-length  for¬ 
mats  were  consolidated  into  approximately  25  ASC  XI 2  EDI  transactions.  More 
than  100  enhancements  for  additional  data  and  new  capabilities  have  also  been 
incorporated  into  the  DLMS  standards. 

The  basic  business  unit  of  EDI  is  a  transaction  set.  For  example,  the  business 
functionality  of  a  DoD  requisition  is  incorporated  in  the  X12  51 1  requisition.  In 
this  case,  this  functionality  is  an  addition  to  the  preexisting  XI 2  standards.  In  an¬ 
other  case,  a  DLSS  ASl  shipment  status  has  been  incorporated  into  the  XI 2  856 
shipment  notice,  a  preexisting  XI 2  transaction  set.  Table  A-1  shows  the  existing 
DLSS  transaction  document  identifier  codes  and  their  XI 2  equivalents. 

Table  A-1.  DLSS  Transaction  Document  Identifier  Codes  and  X12  Equivalents 


ASC  X12  transaction  set 

Number 

Name 

DLSS  document  identifier  codes 

140 

Product  registration 

DSA-D,  DSF,  DSM.  DSR 

180 

Return  merchandise 
authorization  and  notifica¬ 
tion 

FTA,  FTC,  FTE,  FTG,  FTF,  FTT 

511 

Requisition 

A0_,  A3_,  A4_,  AM_,  P1 1 ,  PI 9 

517 

Materiel  obligation  valida¬ 
tion 

AN_,  AP_,  AX_,  AQU,  AQV,  AV_ 

527 

Materiel  due-in  and  receipt 

D4  ,  D6  .  DD  ,  DF  ,  DLC-F,  DU  ,  DW_,  DX_.  DRA-B, 
DRF,  DZK,  P30,  P31,  P32,  P39,  P3T,  P6B  (missing  re¬ 
ceipt) 

536 

Logistics  reassignment 

DLS-X 

561 

Contract  abstract 

PAA-H,  PB1,  PBA-H,  PEI,  PEA-H,  PEK,  PFK 

567 

Contract  completion  status 

PK9,  PKX,  PKZ 

568 

Contract  payment  man¬ 
agement  report 

PV1-5,  PVA 

810 

Invoice 

FA1-2,  FBI -2,  FC1-2,  FD1-2,  FE3-4,  FF1-2,  FG1-2, 

FJ1-2.  FL1-2,  FN1-2,  FP1-2,  FQ1-2.  FR1-2,  FS1-2, 

FU1-2,  FV1-2,  FW1-2,  FX1-2,  and  corresponding  Gs 

812 

Credit  and  debit  adjust¬ 
ment 

FAC,  FAE-F,  FAR-S,  FDC,  FDE-F,  FDR,  FDS,  FJC, 

FJE-F,  FJR-S,  FTB,  FTP,  QBI 

824 

Application  advice 

DZG,  P6S,  P_Z 

830 

Planning  schedule  with 
release  capability 

DMA-E,  DY_ 

842 

Nonconformance  report 

SF361  (TDR),  SF364  (ROD),  SF368  (PQDR) 

846 

Inventory  inquiry  and  ad¬ 
vice 

DJA,  DTA-D,  DZA,  DZE-F,  DZH,  DZJ,  DZL,  DZP, 

DLA-B,  DZC-D,  DAI -2,  DEE-F,  P41,  P6C,  P6D 
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Table  A-1.  DLSS  Transaction  Document  Identifier  Codes  and  X12  Equivalents 

(  Continued) 


ASC  X12  transaction  set 

Number 

Name 

DLSS  document  identifier  codes 

856 

Ship  notice  and  manifest 

AD1-4,  ADR,  AS  ,  AU  ,  FTM,  P20,  P53,  PJJ,  PJR,  PK5, 
TK_ 

858 

Shipping  information 

TBO-9,  TCO,  TC1,  TFO-9,  TGO-9,  THO-9,  TJ1-5,  TJ9, 
TLO-9.  TPO-9,  TUO-9,  TVO-5,  TV9.  TXO-5,  TX9,  T  A-D, 
T_J-M,  “GBL,”  “ITV  receipt” 

861 

Receiving  advice  and 
acceptance  certificate 

PKN,  PKP 

867 

Product  transfer  and  resale 
report 

D7_,  DG_,  DMA,  P21,  P22,  P23,  P28,  P29,  P53 

869 

Order  status  inquiry 

AC1-5,  ACM,  AGP,  AF1-5,  AFR,  AFT,  AFY,  AK1-5, 

AT_1,  P6A 

870 

Order  status  report 

AB_,  ADS,  AE_,  FTD,  FTL,  FTQ,  FTR,  FTZ,  FT6,  D29 

888 

Item  maintenance 

DZB 

940 

Warehouse  shipping  order 

A2_,  A4_,  AS  ,  AC6-7,  ACJ,  AF6,  AFJ,  AFX,  AFZ,  AK6, 
AKJ,  ARM,  P12,  P13,  P18,  P1B,  P1C,  P1H 

945 

Warehouse  shipping  ad¬ 
vice 

ARB 

947 

Warehouse  inventory  ad¬ 
justment  advice 

D8_,  D9_,  DAC-D,  DAS,  DZK,  P42,  P9C,  P9D 

DoD  Manuals  and  Federal  Implementation  Conventions 

The  establishment  of  the  DLMS  transaction  sets  within  the  ASC  XI 2  standards 
represented  merely  the  first  step  of  the  MODELS  development  effort.  To  ensure 
effective  use  of  the  new  transaction  sets,  the  DLMSO  completed  the  following 
actions: 

♦  Revised  the  DLSS  manuals  into  a  single  DLMS  manual  to  reflect  the  new 
transactions  and  established  policies  for  new  data  elements  and  revised 
procedures.^ 

♦  Developed  ICs  that  describe  the  specific  data  elements  and  codes  to  con¬ 
vey  DLMS  data.'*  To  ensure  cooperation  and  consistency  with  the  goals  of 
FIPS  161-2,  the  ICs  were  submitted  to  the  Logistics  Functional  Working 
Group  for  review  before  they  were  submitted  to  the  Federal  EDI  Standards 
Management  Coordinating  Committee  for  approval  as  federal  ICs. 


^  U.S.  Department  of  Defense,  Defense  Logistics  Management  System,  DoD  4000.25-M,  De¬ 
cember  1995. 

The  ASC  XI 2  transaction  sets  are  very  generic.  An  IC  is  a  document  used  by  a  trading 
community  to  define  data  elements  and  their  formats.  The  federal  government  has  specific  proce¬ 
dures  for  establishing  ICs  for  a  transaction  set  to  promote  a  single  face  to  industry. 
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♦  Developed  the  means  to  administer  the  new  system  to  accept  future 

changes.  This  step  includes,  in  conjunction  with  the  participants  reviewing 
and  approving  proposed  changes,  obtaining  ASC  XI 2  approval  of  changes 
and  documenting  the  changes. 

With  these  steps,  DLMS  was  ready  to  be  implemented.  DLMS  implementation 
was  initially  planned  for  incorporation  into  all  the  corporate  information  manage¬ 
ment  systems  developed  by  the  JLSC.  However,  most  systems  were  not  deployed, 
and  this  change  has  delayed  DLMS  implementation  that  now  needs  to  be  incorpo¬ 
rated  into  the  legacy  systems. 


Appendix  B 

Technical  Issues 

DLMS  Processing  Principles 


The  DLMS  brings  new  capabilities  for  exchanging  and  accessing  interservice 
data.  The  capabilities  provide  an  opportunity  to  revise  fundamental  principles  and 
assumptions  about  the  data  sent  and  received  by  computers.  The  following  basic 
principles  should  guide  the  DLMS  processing  actions: 

♦  Edit  at  origin.  To  ensure  the  protection  of  the  receiving  application  soft¬ 
ware,  recipients  will  edit  and,  if  necessary,  reject  and  return  transactions  to 
the  sender.  However,  processing  delays  will  be  eliminated  and  money 
saved  if  no  erroneous  transactions  are  received.  Originating  sites  should 
edit  and  validate  their  transactions  before  sending  them.  Extensive  editing 
and  checking  should  be  designed  into  new  application  interface  programs 
that  generate  DLMS  transactions.  The  edits  should  ensure  that  out¬ 
bound  data  comply  with  DLMS  rules  and  the  requirements  of  the  DoD 
components. 

♦  Eliminate  unnecessary  data.  Currently,  the  DLSS  operate  on  a  whole 
transaction  basis.  Additional  transactions  repeat  a  large  amount  of  the 
original  transaction  data.  In  reality,  only  significant  data  need  be  transmit¬ 
ted.  The  DLMS  should  transmit  only  data  not  already  available  at  the  re¬ 
ceiving  computer.  For  example,  under  DLSS  procedures,  if  a  transmitted 
requisition  is  to  be  canceled,  the  cancellation  transaction  includes  the  en¬ 
tire  original  requisition  and  a  cancel  code.  A  significant  amount  of  the 
original  data,  such  as  the  original  priority  or  advice  data,  is  not  necessary 
in  the  cancellation  transaction  and  will  not  be  included  in  DLMS  ex¬ 
changes.  This  principle  should  also  be  applied  to  images.  All  recipients  do 
not  require  all  data,  and  images  should  be  tailored  to  meet  the  require¬ 
ments  of  specific  users.  The  tailoring  of  images  may  require  modification 
of  both  application  and  application  interface  software. 

♦  Use  data  only  as  defined.  The  space  of  DLSS  transactions  is  limited.  As  a 
result,  the  DoD  components  use  record  positions  assigned  for  interservice 
data  for  internal  uses.  DLMS  EDI  transactions  will  not  have  space  con¬ 
straints  and  will  be  able  to  support  unique  data.  The  DoD  components  are 
encouraged  to  use  those  capabilities,  but  need  to  submit  their  planned  us¬ 
age  to  DLMSO.  All  data  elements  should  carry  only  the  data  defined  in  the 
DLMS  implementation  conventions. 
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ASC  XI 2  EDI  transaction  sets,  including  those  used  by  the  DLMS,  offer  technical 
capabilities  not  available  in  the  DLSS.  These  capabilities  include  providing  sev¬ 
eral  stock  number  transactions  in  an  XI 2  transaction  set  and  an  extensive  capabil¬ 
ity  for  acknowledgment  and  error  reporting.  The  DLMS  stakeholders  need  to 
determine  to  what  extent  the  DLMS  will  use  these  capabilities.  The  following 
subsections  identify  three  major  categories  of  processing  issues — transaction  set 
content,  routing,  and  processing;  transaction  set  tracking  and  control;  and  error 
processing — and  offer  several  recommendations. 

Transaction  Set  Content,  Routing,  and  Processing 

Several  content,  routing,  and  processing  issues  are  related  to  the  groups  of  trans¬ 
actions  and  transaction  sets,  envelope  identification  control,  and  transaction  set 
size. 

Groups  of  Transactions  and  Transaction  Sets 

X12  transaction  sets  can  carry  several  subordinate  transactions  (e.g.,  multiline 
requisitions).  The  subordinate  transactions  can  be  intended  for  different  receiving 
activities.'  Implementing  these  functions  increases  the  complexity  of  the  opening 
and  routing  activities  of  DAASC  as  well  as  the  interface  software  at  the  initiating 
site. 

Recommendation:  Support  a  multitransaction  capacity  within  a  transaction  set,  but 
require  all  transactions  to  be  addressed  to  the  same  recipient  (other  than  DAASC). 

Similarly,  groups  of  similar  transaction  sets  can  be  placed  in  EDI  envelopes  called 
functional  groups.  Several  like  or  diverse  functional  groups  can  be  placed  in  an 
outer  EDI  group  called  an  interchange  set.  The  issue  of  correct  routing  and  multi¬ 
ple  recipients  applies  to  each  level.  All  transaction  sets  in  a  functional  group  need 
to  be  the  same  type  (e.g.,  requisitions),  but  each  transaction  set  does  not  need  to 
have  the  same  destination.  The  DLMS  working  group  needs  to  determine  if  all 
functional  groups  in  an  interchange  set  should  have  the  same  destination. 

Recommendation:  For  the  sake  of  operational  simplicity,  the  following  approaches 
are  recommended; 

♦  For  transactions  that  DAASC  is  not  required  to  open  for  immediate  proc¬ 
essing,  DAASC  will  archive  the  entire  interchange  set  and  may  open  it 
later  for  inclusion  in  LIPS  or  another  database.  However,  DAASC  will  not 
edit  or  alter  the  interchange  set  before  forwarding  it.  The  outer  envelope 


'  For  example,  in  multiline  requisitions,  one  requisition  can  be  intended  for  a  DLA  center  and 
another  for  a  Navy  ICP. 
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and  ISA  segment  of  each  interchange  set  should  identify  the  ultimate  re¬ 
cipient.  All  functional  groups,  transaction  sets,  and  subordinate  transac¬ 
tions  should  be  addressed  to  the  same  recipient. 

♦  For  transactions  that  DAASC  needs  to  open  and  edit  or  process,  the  ISA 
segment  should  identify  DAASC.  The  functional  groups  in  the  interchange 
set  may  be  addressed  to  different  recipients.  Each  group  start  segment  will 
identify  the  recipient,  and  all  transaction  sets  and  their  subordinate  trans¬ 
actions  will  be  addressed  to  that  recipient. 

Envelope  Identmcation  Control 

EDI  interchange  sets,  functional  groups,  and  transaction  sets  contain  provisions 
for  unique  identification  numbers.  Clarification  is  needed  on  how  they  should  be 
used  and  if  any  system  should  be  used  to  standardize  the  identification. 

Adding  information  (for  example,  requisition  numbers  consist  of  a  DoD  activity 
address  code,  Julian  date,  and  serial  number  concatenated  together)  to  a  unique 
identification  number  increases  the  complexity  of  the  process.  However,  begin¬ 
ning  an  identification  number  with  a  unique  code  for  the  originating  organization 
and  including  a  serial  number  for  that  organization  would  benefit  DAASC  ar¬ 
chiving  activities.  The  DLMS  Technical  Working  Group  will  need  to  address  this 
issue. 

Transaction  Set  Size 

The  ASC  X12  transaction  sets  do  not  set  practical  limits  on  the  size  of  a  transac¬ 
tion  and  a  transaction  set.  A  transaction  set  can  be  generated  with  a  size  that 
exceeds  the  capacity  of  the  receiving  site  or  the  telecommunications  path: 

♦  Maximum  size  of  a  single  interchange  set:  one  million  characters  (as 
previously  recommended  by  the  DLMS  Technical  Working  Group) 

♦  Maximum  size  of  a  single  transaction  set:  to  be  evaluated  by  the  DLMS 
Technical  Working  Group 

♦  Maximum  size  of  a  single  transaction:  to  be  evaluated  by  the  DLMS 
Technical  Working  Group. 

Transaction  Set  Tracking  and  Control 

Several  tracking  and  control  issues  are  related  to  the  archiving  and  acknowledg¬ 
ment  actions. 
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All  outbound  transmissions  should  be  archived  at  the  initiating  site  and  be  retriev¬ 
able  for  retransmission  in  case  telecommunications  outages  or  other  failures  pre¬ 
vent  the  receiving  site  from  obtaining  the  data.  Inbound  transactions  should  also 
be  logged. 

The  DLMS  technical  and  functional  working  groups  should  jointly  determine  the 
period  to  maintain  archives  of  outbound  transmissions  (DAASC  maintains  all  in¬ 
bound  and  outbound  archives  for  10  years)  and  the  procedures  for  requesting  a 
retransmission. 

Acknowledgments 

Many  DLSS  transactions,  particularly  in  the  requisition  process,  provide  the  re¬ 
cipient  a  capability  to  acknowledge  receipt,  provide  functional  status  to  the  origi¬ 
nator,  and  return  rejected  transactions.  These  capabilities  have  been  incorporated 
in  the  corresponding  DLMS  transactions  sets.  However,  EDI  offers  the  opportu¬ 
nity  for  additional  acknowledgments.  As  indicated  by  Part  10  of  the  Federal 
Implementation  Guidelines  for  EDI,  the  following  events  can  occur: 

♦  DAASC  (acting  as  an  ECPN  of  DISA)  returns  a  242  transaction  set  to  the 
point  of  outbound  translation.  If  DAASC  does  not  provide  a  positive  re¬ 
sponse  within  2  hours,  the  point  of  translation  sends  a  242  inquiry. 

♦  When  DAASC  forwards  a  transaction  to  a  VAN,  DAASC  receives  a  TA3 
segment  as  an  acknowledgment  in  a  manner  similar  to  the  action  of  the 
242  transaction  set.  DAASC  also  returns  a  TA3  to  a  VAN.^ 

♦  When  DAASC  forwards  a  transaction  to  another  DoD  site,  DAASC 
receives  a  997  transaction  set  that  is  forwarded  to  the  originator. 

The  997  transaction  set  is  the  key  to  the  standard  XI 2  acknowledgment  model 
used  by  industry.  The  transaction  set  indicates  that  the  receiving  EDI  translation 
software  received  the  transaction.  The  997  transaction  set  can  perform  syntax 
checks  of  the  incoming  envelope  and  its  transaction  sets  and  respond  in  the 
following  ways: 

♦  The  997  transaction  set  can  acknowledge  a  positive  acceptance  of  the 
transmission  as  a  whole,  acknowledge  an  acceptance  with  errors,  or  reject 
the  entire  transmission  (usually  only  for  errors  in  the  envelope). 

♦  The  997  transaction  set  can  perform  the  same  acknowledgment  and 
rejection  actions  on  a  transaction-by-transaction  basis. 


^  A  VAN  is  a  commercial  organization  that  acts  as  a  hub  to  store  and  forward  EDI  communi¬ 
cations. 
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Technical  Issues 


The  use  of  the  997  transaction  set  raises  several  issues  that  the  DLMS  community 
needs  to  resolve.  The  number  of  DLMS  transactions  will  be  very  large.  The 
DLMS  working  group  needs  to  determine  if  the  higher  level  caused  by  acknowl¬ 
edgments  is  desirable  (e.g.,  the  critical  requisition  process  already  includes  status 
capabilities).  However,  for  DLMS  transaction  sets  that  do  not  have  status  re¬ 
sponses,  the  997  could  be  used  (e.g.,  with  DoD  invoices).  The  997  transaction  set 
responses  can  also  be  tailored  to  acknowledge  the  receipt  of  an  envelope  and  re¬ 
turn  transaction-level  data  only  if  an  XI 2  syntax  error  is  identified  for  a  transac¬ 
tion  set.  This  approach  dramatically  reduces  the  number  of  responses  if  several 
transaction  sets  are  grouped  in  a  message  envelope. 

In  addition,  the  997  transaction  set  processes  errors  only  for  the  XI 2  data  stan¬ 
dards.  For  example,  errors  occur  when  a  mandatory  data  element  is  not  sent,  a 
data  element  is  too  long,  or  a  date  is  formatted  incorrectly.  However,  a  translator 
does  not  correlate  those  errors  to  the  IC  or  functional  data.  For  example,  a  trans¬ 
lator  does  not  identify  an  incorrect  requisition  format.  The  997  transaction  set  also 
provides  receipt  only  from  the  inbound  translation  software — not  to  the  receiving 
application  system.  If  the  translator  is  collocated  with  the  receiving  application 
system,  an  assumption  can  be  reasonably  made  that  receipts  were  also  received  by 
the  application  system.  However,  if  the  translation  software  is  regionally  based 
(for  example,  DLA  performs  translation  at  Richmond,  Virginia,  for  a  non-DLMS 
application  system  in  Utah)  or  the  translation  is  performed  by  DAASC,  an  as¬ 
sumption  cannot  be  made  that  the  997  transaction  set  is  the  equivalent  of  a 
receipt  by  the  final  application  system. 

Recommendation:  The  previous  DLMS  Functional  Working  Group  decided  not  to 
use  the  997  transaction  set  (except  for  finance  transactions).  The  current  group 
should  review  this  decision  and  revalidate  or  revise  it.  We  recommend  that  if  the 
997  transaction  set  is  to  be  used,  it  be  used  only  to  acknowledge  a  message  and 
provide  notification  of  transactions  containing  errors.  This  review  should  be  made 
for  each  transaction  set  and  needs  to  consider  other  decisions  related  to  transaction 
set  groups  and  the  use  of  the  TA3  and  242.  Figure  B-1  is  a  simple  view  of  one  of 
the  many  approaches  that  can  be  used  for  acknowledgments.  (The  figure  does  not 
include  the  use  by  DAASC  of  an  EDI  translator  that  returns  an  acknowledgment.) 
The  initiator  sends  a  requisition  that  passes  through  DAAS  to  the  recipient’s  EDI 
translator.  This  program  generates  a  997  functional  acknowledgment.  The 
receiving  translator  can  be  mapped  to  send  a  997  to  acknowledge  only  the  group 
(of  one  or  more  requisitions),  acknowledge  each  requisition,  or  acknowledge  one 
or  more  requisitions  with  EDI  syntax  errors.  After  the  translator  processes  the 
requisition,  the  UDF — ^labeled  UDF2  because  it  may  not  be  the  same  format  that 
the  requisitioning  system  uses — ^is  sent  to  the  ICP  requisition  module.  The  system 
edits  the  requisition  and  determines  the  supply  status.  An  870  supply  status  is  re¬ 
turned.  In  this  example,  DAASC  is  portrayed  as  the  only  middleman.  In  other  cir¬ 
cumstances,  a  contractor’s  requisition  can  flow  through  the  contractor’s  VAN  to  a 
DISA  ECPN  to  be  sent  through  DAAS  to  the  receiving  ICP.  The  X12  standards 
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include  an  acknowledgment  that  is  exchanged  between  the  two  middlemen  to 
archive  transaction  routing  and  timing. 


Figure  B-1.  One  Approach  for  Acknowledgments 


Error  Processing 

One  function  of  the  interface  program  is  to  validate  the  data  to  ensure  they  do  not 
damage  the  receiving  application.  A  key  question  is  how  much  error  checking  the 
program  should  do.  If  all  participants  carefully  edit  their  transactions  when  they 
are  created,  bad  data  should  not  occur.  However,  maintainers  of  receiving  soft¬ 
ware  will  not  want  to  risk  the  consequences  of  receiving  bad  data.  Even  after 
30  years  of  operating  with  the  DLSS,  DAASC  still  rejects  nearly  1  percent  of  all 
incoming  transactions.  The  implementation  testing  of  DLMS  will  initially 
produce  a  significantly  higher  number  of  rejections. 

When  translators,  application  interface  programs,  or  application  software  detect  an 
error,  a  means  is  needed  to  communicate  the  error  to  the  recipient.  For  ASC  XI 2 
syntax  errors  discovered  by  the  translator,  the  typical  means  is  to  return  a  997 
functional  acknowledgment  transaction  set.  However,  business  errors  are  commu¬ 
nicated  by  other  means.^  One  alternative  is  for  the  receiving  application  program 
to  respond  to  the  originator  with  an  824  application  advice  transaction  set  with 
error  codes.  The  DLMS  trading  partners  need  to  agree  on  this  transaction  set  or 
other  reporting  means. 


^  Business  errors  include  submitting  requisitions  for  a  quantity  of  zero,  excess  quantities,  or  an 
item  that  the  requisitioner  is  not  authorized  to  acquire. 


Technical  Issues 


The  DLMS  architecture  anticipates  that  DLMS  commercial  participants  will  be 
connected  to  DAASC  through  a  commercial  VAN  (although  they  may  also  be 
connected  to  a  megacenter  and  DAASC  for  non-DLMS  EDI).  Commercial  or¬ 
ganizations  exchanging  EDI  transactions  (DLMS  or  others)  with  DoD  have  to 
register  with  DISA  and  use  a  DISA-approved  VAN.  For  example,  a  DoD  requisi¬ 
tion  issued  by  a  commercial  vendor  is  translated  to  a  DLMS  EDI  format  by  the 
organization  and  sent  to  the  following  activities: 

♦  Vendor’s  VAN 

♦  DAASC 

♦  Receiving  DoD  activity. 

Unique  Data 

In  actuality,  the  issue  of  unique  data  is  simply  another  processing  issue;  however, 
this  topic  is  so  important  an  issue  that  we  address  it  separately.  The  DoD 
components  have  the  following  two  types  of  unique  data: 

♦  Unique  data  elements  carried  in  the  DLSS  transactions 

♦  Unique  data  elements  transmitted  outside  the  DLSS  as  unique  transac¬ 
tions. 

The  first  type  is  relatively  simple  to  address.  All  DLMS  transaction  sets  have  data 
elements  that  can  carry  unique  data  elements.  The  DoD  components  can  provide 
DLMSO  with  the  data  elements  by  DLMS  transactions  and  associated  data  for¬ 
mats  and  code  lists  so  the  data  elements  can  be  documented  in  the  ICs  and  related 
DLMS  documentation. 

The  second  set  represents  a  more  substantial  challenge.  Although  no  review  has 
been  conducted  to  provide  the  rationale  for  these  types  of  unique  data  elements, 
anecdotal  evidence  supports  the  view  that  DoD  components  need  to  transmit  data 
that  the  DLSS  does  not  support.  As  a  result,  the  DoD  components  developed  their 
own  transactions  as  they  modernized  their  logistics  programs.  Many  transactions 
are  DLSS-like  and  are  documented  in  manuals  of  the  DoD  components.  However, 
many  variable-length  transactions  that  have  been  developed  recently  are  not  well- 
documented.  The  amount  of  these  transactions  and  the  number  of  transaction 
types  may  well  exceed  those  of  DLSS  transactions.  These  variable-length 
transactions  can  be  segregated  into  the  following  three  categories: 

♦  Transactions  that  contain  significant  data  that  can  be  added  to  a  DLMS 
transaction  set 
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♦  Transactions  (e.g.,  maintenance)  that  are  not  reflected  in  the  DLMS  and 
are  similar  to  transactions  used  by  another  DoD  component'* 

♦  Transactions  that  can  be  converted  to  X12  transaction  sets  consistent  in 
style  with  the  DLMS,  but  maintained  by  a  DoD  component. 

Configuration  Control 

Changes  to  any  standard  system  used  by  a  large  community  need  to  be  limited  to 
prevent  increased  system  maintenance  costs;  however,  the  system  needs  to  evolve 
to  meet  new  requirements  and  support  new  technical  innovations.  This  issue  was 
certainly  prevalent  in  the  DLSS  environment.  However,  implementing  a  major 
DLSS  change  for  all  systems  of  the  DoD  components  frequently  took  7  years. 

This  lengthy  implementation  period  is  one  rationale  for  establishing  the  DLMS. 
Using  ASC  XI 2  standards  for  the  DLMS  requires  that  configuration  control  of 
both  the  DLMS  release  and  the  ASC  X12  standards  be  maintained. 

DLMS  Configuration  Control 

All  transaction  sets  will  comply  with  the  implementation  conventions  defined  in 
the  DLMS  manual  for  transmissions  within  and  among  DLMS  participants.  When 
DoD  components  require  a  modification  of  the  DLMS  implementation  conven¬ 
tions  to  meet  new  data  requirements,  they  should  submit  a  request  to  the  DLMS 
Process  Review  Committee  using  procedures  defined  in  the  DLMS  manual.  If  the 
change  requires  a  modification  to  the  underlying  ASC  XI 2  standards,  DLMSO 
will  work  with  the  Federal  EDI  Standards  Maintenance  Coordinating  Committee 
to  submit  the  change  to  XI 2. 

ASC  XI 2  CONnCURATION  CONTROL 

All  DLMS  trading  partners  need  to  use  the  same  version  and  release  of  the 
DLMS,  and  their  EDI  translators  need  to  use  the  same  version  and  release  of  ASC 
X12  standards.  Although  the  ASC  X12  standards  are  updated  only  annually, 
translation  software  is  required  to  support  the  last  four  ASC  XI 2  versions  and  re¬ 
leases.  Therefore,  if  revisions  to  the  XI 2  standards  do  not  affect  the  DLMS, 
DLMS  EDI  translators  need  to  be  updated  to  reflect  the  most  current  ASC  XI 2 
standards  only  once  every  4  years.  However,  updates  will  probably  be  necessary 
more  frequently  to  reflect  changes  in  the  XI 2  standards  that  affect  the  DLMS. 


''  These  unique  transactions  can  be  combined  into  a  single  standard  transaction  set. 
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ADP 

automated  data  processing 

ANSI 

American  National  Standards  Institute 

ASC 

Accredited  Standards  Committee 

AUTODIN 

Automatic  Digital  Network 

C4ISR 

command,  control,  communications,  computers,  intelligence,  sur¬ 
veillance,  and  reconnaissance 

CAGE 

commercial  and  government  entity 

CAV 

Commercial  Asset  Visibility 

CDA 

central  design  agency 

COE 

common  operating  environment 

CONUS 

continental  United  States 

COTS 

commercial  off-the-shelf 

DAAS 

Defense  Automatic  Addressing  System 

DAASC 

Defense  Automatic  Addressing  System  Center 

DFAS 

Defense  Finance  and  Accounting  Service 

DD 

Defense  Information  Infrastructure 

DISA 

Defense  Information  Systems  Agency 

DISN 

Defense  Information  System  Network 

DLA 

Defense  Logistics  Agency 

DLIS 

Defense  Logistics  Information  Service 

DLMS 

Defense  Logistics  Management  System 
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DLMSO 

Defense  Logistics  Management  Standards  Office 

DLSS 

Defense  Logistics  Standard  Systems 

DoD 

Department  of  Defense 

DoDAAC 

Department  of  Defense  Activity  Address  Code 

DoDAAD 

Department  of  Defense  Activity  Address  Directory 

DRMS 

Defense  Reutilization  and  Marketing  Service 

DUNS 

data  universal  numbering  system 

DUSD(L) 

Deputy  Under  Secretary  of  Defense  (Logistics) 

DVD 

direct  vendor  delivery 

EC 

electronic  commerce 

ECPN 

electronic  commerce  processing  node 

EDI 

electronic  data  interchange 

FEDSTRIP 

Federal  Standard  Requisition  and  Issue  Procedures 

FIPS 

Federal  Information  Processing  Standard 

GBL 

government  bill  of  lading 

GCSS 

Global  Combat  Support  System 

GDMS 

Global  Database  Management  System 

GSA 

General  Services  Administration 

IC 

implementation  convention 

ICP 

inventory  control  point 

ILCS 

International  Logistics  Communications  System 

rrv 

in-transit  visibility 

JCS 

Joint  Chiefs  of  Staff 

JECPO 

Joint  Electronic  Commerce  Program  Office 
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Abbreviations 


JLSC  Joint  Logistics  Systems  Center 

JTA  Joint  Technical  Architecture 

LAN  local  area  network 

LIPS  Logistics  Information  Processing  System 

LITA  Logistics  Infrastructure  Technical  Architecture 

LOGDESMAP  Logistics  Data  Element  Standardization  and  Management  Program 

MAP  AD  Military  Assistance  Program  Address  Directory 

MILS  military  standard 

MILSBILLS  Military  Standard  Billing  System 

MILSCAP  Military  Standard  Contract  Administration  Procedures 

MILSPETS  Military  Standard  Petroleum  System 

MILSTAMP  Military  Standard  Transportation  and  Movement  Procedures 

MBLSTEP  Military  Standard  Supply  and  Transportation  Evaluation  Procedures 

MDLSTRAP  Military  Standard  Transaction  Reporting  and  Accounting  Procedures 

MILSTRIP  Military  Standard  Requisitioning  and  Issue  Procedures 

MODELS  Modernization  of  the  Defense  Logistics  Standard  Systems 

NIMA  National  Imagery  and  Mapping  Agency 

NEPRNET  Nonsecure  Internet  Protocol  Router  Network 

NSN  national  stock  number 


OSD  Office  of  the  Secretary  of  Defense 

PQDR  product  quality  deficiency  report 

PRC  process  review  committee 

ROD  report  of  discrepancy 

SDR  supply  discrepancy  report 


D-3 


TAV 

total  asset  visibility 

TCN 

transportation  control  number 

TDR 

transportation  discrepancy  report 

TRC 

Technical  Review  Committee 

UDF 

user  defined  file 

VAN 

value-added  network 

WAN 

wide  area  network 

WFN 

wide  frequency  network 

Y2K 

year  2000 
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